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:4.026 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site