Linus Torvalds writes:
>
>
> 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.
Exactly. Would that it were so easy :-)
> > > 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.
You mean define a FS-specific structure and point generic_ip to 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.
But this isn't quite what I want. Al's multi-mount work will
complement the devfs multi-mount stuff, and I'm glad to see it, but
it's not quite the same.
In devfs, we want to mount it once over /dev and expose all device
entries in the devfs namespace.
BUT: we also want to mount it inside a chroot() gaol, but with the
"explicit" mount option. This option prevents entries in the devfs
namespace from appearing in the mounted FS until such time as root
goes in and does mknod(2) and such. This way, only those device nodes
the admin wants to expose to the gaol will be exposed. Everything else
is hidden (and inaccessible).
As I understand Al's multi-mount work, there isn't a way of doing
this.
> > How do I tunnel
> > through to the underlying disc-based FS to save&restore permissions
> > (WIP)?
>
> At bootup.
How? And just doing it at bootup isn't enough. Sometime later the
sysadmin does chmod(2) on /dev/floppy/0. That change has to be pushed
through to the underlying FS.
So that's more code you won't find in RAMFS ;-)
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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