On Mon, Mar 9, 2020 at 11:53 PM David Howells <dhowells@xxxxxxxxxx> wrote: > > Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > (1) It can be targetted. It makes it easy to query directly by path or > > > fd, but can also query by mount ID or fscontext fd. procfs and sysfs > > > cannot do three of these things easily. > > > > See above: with the addition of open(path, O_PATH) it can do all of these. > > That's a horrible interface. To query a file by path, you have to do: > > fd = open(path, O_PATH); > sprintf(procpath, "/proc/self/fdmount/%u/<attr>"); > fd2 = open(procpath, O_RDONLY); > read(fd2, ...); > close(fd2); > close(fd); > > See point (3) about efficiency also. You're having to open *two* files. I completely agree, opening two files is surely going to kill performance of application needing to retrieve a billion mount attributes per second.</sarcasm> > > > (2) Easier to provide LSM oversight. Is the accessing process allowed to > > > query information pertinent to a particular file? > > > > Not quite sure why this would be easier for a new ad-hoc interface than for > > the well established filesystem API. > > You're right. That's why fsinfo() uses standard pathwalk where possible, > e.g.: > > fsinfo(AT_FDCWD, "/path/to/file", ...); > > or a fairly standard fd-querying interface: > > fsinfo(fd, "", { resolve_flags = RESOLVE_EMPTY_PATH }, ...); > > to query an open file descriptor. These are well-established filesystem APIs. Yes. The problem is with the "..." part where you pass random structures to a function. That's useful sometimes, but at the very least it breaks type safety, and not what I would call a "clean" API. > > Now onto the advantages of a filesystem based API: > > > > - immediately usable from all programming languages, including scripts > > This is not true. You can't open O_PATH from shell scripts, so you can't > query things by path that you can't or shouldn't open (dev file paths, for > example; symlinks). Yes. However, you just wrote the core of a utility that could do this (in 6 lines, no less). Now try that feat with fsinfo(2)! Thanks, Miklos