On Mon, 2020-08-03 at 18:42 +0200, Miklos Szeredi wrote: > On Mon, Aug 3, 2020 at 5:50 PM David Howells <dhowells@xxxxxxxxxx> > wrote: > > > > Hi Linus, > > > > Here's a set of patches that adds a system call, fsinfo(), that > > allows > > information about the VFS, mount topology, superblock and files to > > be > > retrieved. > > > > The patchset is based on top of the mount notifications patchset so > > that > > the mount notification mechanism can be hooked to provide event > > counters > > that can be retrieved with fsinfo(), thereby making it a lot faster > > to work > > out which mounts have changed. > > > > Note that there was a last minute change requested by Miklós: the > > event > > counter bits got moved from the mount notification patchset to this > > one. > > The counters got made atomic_long_t inside the kernel and __u64 in > > the > > UAPI. The aggregate changes can be assessed by comparing pre- > > change tag, > > fsinfo-core-20200724 to the requested pull tag. > > > > Karel Zak has created preliminary patches that add support to > > libmount[*] > > and Ian Kent has started working on making systemd use these and > > mount > > notifications[**]. > > So why are you asking to pull at this stage? > > Has anyone done a review of the patchset? I have been working with the patch set as it has evolved for quite a while now. I've been reading the kernel code quite a bit and forwarded questions and minor changes to David as they arose. As for a review, not specifically, but while the series implements a rather large change it's surprisingly straight forward to read. In the time I have been working with it I haven't noticed any problems except for those few minor things that I reported to David early on (in some cases accompanied by simple patches). And more recently (obviously) I've been working with the mount notifications changes and, from a readability POV, I find it's the same as the fsinfo() code. > > I think it's obvious that this API needs more work. The integration > work done by Ian is a good direction, but it's not quite the full > validation and review that a complex new API needs. Maybe but the system call is fundamental to making notifications useful and, as I say, after working with it for quite a while I don't fell there's missing features (that David hasn't added along the way) and have found it provides what's needed for what I'm doing (for mount notifications at least). I'll be posting a github PR for systemd for discussion soon while I get on with completing the systemd change. Like overflow handling and meson build system changes to allow building with and without the util-linux libmount changes. So, ideally, I'd like to see the series merged, we've been working on it for quite a considerable time now. Ian
