lkml.org 
[lkml]   [2020]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 00/18] VFS: Filesystem information [ver #21]
    From
    Date
    On Mon, 2020-08-03 at 14:36 +0100, David Howells wrote:
    > Here's a set of patches that adds a system call, fsinfo(), that
    > allows information about the VFS, mount topology, superblock and
    > files to be retrieved.
    >
    > The patchset is based on top of the notifications patchset and allows
    > event counters implemented in the latter to be retrieved to allow
    > overruns to be efficiently managed.

    Could I repeat the question I asked about six months back that never
    got answered:

    https://lore.kernel.org/linux-api/1582316494.3376.45.camel@HansenPartnership.com/

    It sort of petered out into a long winding thread about why not use
    sysfs instead, which really doesn't look like a good idea to me.

    I'll repeat the information for those who want to quote it easily on
    reply without having to use a web interface:

    ---
    Could I make a suggestion about how this should be done in a way that
    doesn't actually require the fsinfo syscall at all: it could just be
    done with fsconfig. The idea is based on something I've wanted to do
    for configfd but couldn't because otherwise it wouldn't substitute for
    fsconfig, but Christian made me think it was actually essential to the
    ability of the seccomp and other verifier tools in the critique of
    configfd and I belive the same critique applies here.

    Instead of making fsconfig functionally configure ... as in you pass
    the attribute name, type and parameters down into the fs specific
    handler and the handler does a string match and then verifies the
    parameters and then acts on them, make it table configured, so what
    each fstype does is register a table of attributes which can be got and
    optionally set (with each attribute having a get and optional set
    function). We'd have multiple tables per fstype, so the generic VFS
    can register a table of attributes it understands for every fstype
    (things like name, uuid and the like) and then each fs type would
    register a table of fs specific attributes following the same pattern.
    The system would examine the fs specific table before the generic one,
    allowing overrides. fsconfig would have the ability to both get and
    set attributes, permitting retrieval as well as setting (which is how I
    get rid of the fsinfo syscall), we'd have a global parameter, which
    would retrieve the entire table by name and type so the whole thing is
    introspectable because the upper layer knows a-priori all the
    attributes which can be set for a given fs type and what type they are
    (so we can make more of the parsing generic). Any attribute which
    doesn't have a set routine would be read only and all attributes would
    have to have a get routine meaning everything is queryable.

    I think I know how to code this up in a way that would be fully
    transparent to the existing syscalls.
    ---

    James



    \
     
     \ /
      Last update: 2020-08-04 17:40    [W:5.401 / U:0.428 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site