Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH 00/14] VFS: Filesystem information [ver #18] | Date | Mon, 09 Mar 2020 22:52:53 +0000 |
| |
Miklos Szeredi <miklos@szeredi.hu> 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
| |