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
