On Mon, Jun 2, 2025 at 8:40 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > 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. Sounds good! I will prepare v2 with a flags field. Thanks, Song
