On Wed, Aug 12, 2020 at 8:33 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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
