Linus Torvalds writes:
>
>
> On Wed, 12 Apr 2000, Richard Gooch wrote:
> > > 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?
>
> Yes. Or, if the FS-specific field is small enough, then just make it
> part of the union of FS-specific stuff.
Fine. Actually, one day I hope to see the union blown away and every
FS just write a pointer.
> > 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.
>
> "underlying FS"?
>
> There doesn't _need_ to be anything underlying.
>
> Look at how ramfs does the above. chmod() works wonderfully well on ramfs.
> Without any actual support for it. Think about it.
>
> > So that's more code you won't find in RAMFS ;-)
>
> But that is the POINT. You don't need it in the FS, if you just get rid of
> the "underlying" part.
>
> What you are arguing for is to maintain the meta-data on your own. You're
> missing my argument which is that you should not even _need_ to maintain
> it, because the VFS layer does a wonderful job of maintenance for you.
>
> What do you buy by having a separate backing store (aka "underlying
> FS")? Not much.
No, you're missing my point. Look back and you'll see I said
"underlying disc-based FS". In other words, tunnel through to the FS
that devfs is mounted on (i.e. /) and read/write permissions
there. That's to get persistence across reboots. I'm not talking about
persistence while booted.
This is one of the things Ted complained about early on, that devfs
didn't do this right from the start, requiring the "tar kludge" to
save and restore permissions.
And you didn't answer how I can have different permissions, or simply
not expose device entries, on a selective basis, *and have different
selections each time you mount devfs*. This is important for chroot()
gaols.
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