On Wed, 12 Apr 2000, Richard Gooch wrote:
>
> The lookup() method for devfs won't be that simple, because I have to
> pass failed lookup events to devfsd.
Well, it will be more than three lines, yes.
> > Btw, richard, this approach would lend itself quite well to devfs
> > too.
>
> I'm not so sure. Where do I store my FS-specific data?
You have complete control over the inode that gets created. You can put
anything you want into it, and you never need to save it away - because
the inode will stay around until the file is deleted.
For example, ramfs will save away the symbolic link information in the
page cache associated with the inode. But it could have a filesystem
specific part the way all the other filesystems have - it's just that
ramfs doesn't need it.
> How do I
> register device entries before the FS is mounted? How do I maintain a
> single tree of device entries and mount it multiple times (once for
> /dev, and once each for each class of chroot() gaol)?
This is the main part that is missing right now, but all the
infrastructure is actually there right now. Thanks to Al Viro, btw.
The work done by Al means that not only can you export the same dentry
tree at multiple points - it actually also allows a dentry tree that isn't
even exported yet ("exported" basically means "mounted" - the act of
mounting will expose the dentry tree to the user). This is hugely useful
even for regular filesystems - for loopback mounts where the same
filesystem is mounted at multiple points in the filesystem hierarchy
(autofs finds this very useful, but so does chroot environments etc).
For virtual filesystems like /proc, it means that you can have a single
dentry tree, and it will show up in multiple places without any race
conditions or aliasing.
> How do I tunnel
> through to the underlying disc-based FS to save&restore permissions
> (WIP)?
At bootup.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:20 EST