lkml.org 
[lkml]   [2020]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: file metadata via fs API (was: [GIT PULL] Filesystem Information)
    On Wed, Aug 12, 2020 at 8:33 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
    >
    > On Wed, Aug 12, 2020 at 06:39:11PM +0100, Al Viro wrote:
    > > On Wed, Aug 12, 2020 at 07:16:37PM +0200, Miklos Szeredi wrote:
    > > > On Wed, Aug 12, 2020 at 6:33 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
    > > > >
    > > > > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
    > > >
    > > > > > Why does it have to have a struct mount? It does not have to use
    > > > > > dentry/mount based path lookup.
    > > > >
    > > > > What the fuck? So we suddenly get an additional class of objects
    > > > > serving as kinda-sorta analogues of dentries *AND* now struct file
    > > > > might refer to that instead of a dentry/mount pair - all on the VFS
    > > > > level? And so do all the syscalls you want to allow for such "pathnames"?
    > > >
    > > > The only syscall I'd want to allow is open, everything else would be
    > > > on the open files themselves.
    > > >
    > > > file->f_path can refer to an anon mount/inode, the real object is
    > > > referred to by file->private_data.
    > > >
    > > > The change to namei.c would be on the order of ~10 lines. No other
    > > > parts of the VFS would be affected.
    > >
    > > If some of the things you open are directories (and you *have* said that
    > > directories will be among those just upthread, and used references to
    > > readdir() as argument in favour of your approach elsewhere in the thread),
    > > you will have to do something about fchdir(). And that's the least of
    > > the issues.
    >
    > BTW, what would such opened files look like from /proc/*/fd/* POV? And
    > what would happen if you walk _through_ that symlink, with e.g. ".."
    > following it? Or with names of those attributes, for that matter...
    > What about a normal open() of such a sucker? It won't know where to
    > look for your ->private_data...
    >
    > FWIW, you keep refering to regularity of this stuff from the syscall
    > POV, but it looks like you have no real idea of what subset of the
    > things available for normal descriptors will be available for those.

    I have said that IMO using a non-seekable anon-file would be okay for
    those. All the answers fall out of that: nothing works on those
    fd's except read/write/getdents. No fchdir(), no /proc/*/fd deref,
    etc...

    Starting with a very limited functionality and expanding on that if
    necessary is I think a good way to not get bogged down with the
    details.

    Thanks,
    Miklos

    \
     
     \ /
      Last update: 2020-08-18 11:31    [W:4.506 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site