On Fri, 7 Apr 2000, Richard Gooch wrote:
> >
> > Yes, that's what /proc/sys has gotten absolutely correct. This is a
> > Good Thing[TM].
>
> So if we removed the magic ID's (and sysctl(2)), Linus would be happy?
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.
One of the arguments against /proc as opposed to sysctl() has been
complexity and size: this thing is _small_. It uses the VFS logic (which
has to be there anyway if you have any filesystem at all) to do all the
maintenance. Add number parsing and output, and you have a sysctl()
without all the sysctl()-specific crud.
Btw, richard, this approach would lend itself quite well to devfs too.
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:12 EST