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.
Note that the advantage of the RAMFS approach is that usually the
fs-specific part is really really small, especially if there is no need
for backing store. In many cases, the logic to maintain the backing store
for the inodes etc is actually what takes up quite a lot of the resources.
With the approach of just populating the VFS caches directly, all of that
just goes away.
What do you really need that is devfs-specific? Looking at thedevfs
notification structure, there's _nothing_ that isn't already part of the
standard inode information.. Your "devfs_entry" would just go away, to
instead just be a dentry with a pointer to the inode.
> > 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.
"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.
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