Linus Torvalds writes:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to mime@docserver.cac.washington.edu for more info.
Yuk! MIME!
> The actual internal implementation of sysctl() is horribly unclear. I'd
> rather have a dentry tree where the dentries contain the filenames
> (obviously) and also the values (in the private field or in the inode).
> That makes adding and removing entries quite trivial.
>
> As an example, let me append the ramfs thing I wrote as a dynamic ramdisk,
> and note how it leaves everything in the VFS caches. This is how any
> virtual filesystem should end up looking some day (Al Viro is looking at
> making /proc use this approach too - get rid of the "proc_directory_entry"
> thing, and just use the VFS layer dentry instead).
>
> Ignore the data side: that's obviously only useful for a RAM-disk,
> but note how "lookup()" is 3 lines long, and how "mkdir()" and
> friends are truly trivial.
The lookup() method for devfs won't be that simple, because I have to
pass failed lookup events to devfsd.
> 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? 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)? How do I tunnel
through to the underlying disc-based FS to save&restore permissions
(WIP)?
There's a bunch of other things that need to be done for a real
devfs. I'm not sure that there's all that much saving to be made.
> Content-Type: TEXT/PLAIN; charset=US-ASCII; name="inode.c"
> Content-Transfer-Encoding: BASE64
> Content-ID: <Pine.LNX.4.10.10004090806530.1433@penguin.transmeta.com>
> Content-Description:
> Content-Disposition: attachment; filename="inode.c"
This had a pile of control-M characters in it :-(
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