lkml.org 
[lkml]   [2020]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 00/14] VFS: Filesystem information [ver #18]
Date
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

\
 
 \ /
  Last update: 2020-03-09 23:54    [W:0.121 / U:1.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site