On Mon, Jun 2, 2025 at 6:27 AM Song Liu <song@xxxxxxxxxx> wrote: > > On Mon, Jun 2, 2025 at 2:27 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > On Thu, May 29, 2025 at 11:00:51AM -0700, Song Liu wrote: > > > On Thu, May 29, 2025 at 10:38 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Thu, May 29, 2025 at 09:53:21AM -0700, Song Liu wrote: > > > > > > > > > Current version of path iterator only supports walking towards the root, > > > > > with helper path_parent. But the path iterator API can be extended > > > > > to cover other use cases. > > > > > > > > Clarify the last part, please - call me paranoid, but that sounds like > > > > a beginning of something that really should be discussed upfront. > > > > > > We don't have any plan with future use cases yet. The only example > > > I mentioned in the original version of the commit log is "walk the > > > mount tree". IOW, it is similar to the current iterator, but skips non > > > mount point iterations. > > > > > > Since we call it "path iterator", it might make sense to add ways to > > > iterate the VFS tree in different patterns. For example, we may > > > > No, we're not adding a swiss-army knife for consumption by out-of-tree > > code. I'm not opposed to adding a sane iterator for targeted use-cases > > with a clear scope and internal API behavior as I've said multiple times > > already on-list and in-person. > > > > I will not merge anything that will endup exploding into some fancy > > "walk subtrees in any order you want". > > We are not proposing (and AFAICT never proposed) to have a > swiss-army knife that "walk subtrees in any order you want". Instead, > we are proposing a sane iterator that serves exactly one use case > now. I guess the concern is that it looks extensible. However, I made > the API like this so that it can be extended, with thorough reviews, to > cover another sane use case. If there is still concern with this. We > sure can make current code not extensible. In case there is a > different sane use case, we will introduce another iterator after > thorough reviews. It's good that the iterator is extensible, but to achieve that there is no need to introduce "enum bpf_path_iter_mode" which implies some unknown walk patterns. Just add "u64 flags" to bpf_iter_path_new() and if (!flags) return -EINVAL; Then we'll have a way to extend that kfunc if really necessary. Deleting and introducing new kfuncs/iterators is not a big deal, but reserving 'flags' as an option for extension is almost always a good backup.
