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.
> > (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.
Where I vary from this is allowing direct specification of a mount ID also,
with a special flag to say that's what I'm doing:
fsinfo(AT_FDCWD, "23", { flags = FSINFO_QUERY_FLAGS_MOUNT }, ...);
> > (7) Don't have to create/delete a bunch of sysfs/procfs nodes each time a
> > mount happens or is removed - and since systemd makes much use of
> > mount namespaces and mount propagation, this will create a lot of
> > nodes.
>
> This patch creates a single struct mountfs_entry per mount, which is 48bytes.
fsinfo() doesn't create any. Furthermore, it seems that mounts get multiplied
8-10 times by systemd - though, as you say, it's not necessarily a great deal
of memory.
> 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).
I imagine you're thinking of something like:
{
id=`cat /proc/self/fdmount/5/parent_mount`
} 5</my/path/to/my/file
but what if /my/path/to/my/file is actually /dev/foobar?
I've had a grep through the bash sources, but can't seem to find anywhere that
uses O_PATH.
> - same goes for future extensions: no need to update libc, utils, language
> bindings, strace, etc...
Applications and libraries using these attributes would have to change anyway
to make use of additional information.
But it's not a good argument since you now have to have text parsers that
change over time.
David
