> We don't seem to have anything that absolutely relies on procfs or
> kernfs.

Right - at present.  What started this, though, was my remark that I
kept hearing "this would be neat, but kernfs is optional" and that
maybe it was time to make it non-optional, or at least recommended.

Same goes for procfs, though it would take more thought and effort to
get it in shape to make non-optional.

> kernfs just makes information more readily available via 'files' as
> opposed to groveling in the kernel for things like boottime, loadav
> and the like.

As someone (chris?) pointed out, nearly everything in kernfs is
currently available via sysctl too.

But this is unlikely to ever be the case with the suggestion that
started all this, which was to put something in kernfs which was the
kernel as it appeared on-disk before boot.  I somehow doubt this would
ever go into sysctl.

And some of us (me, for example) just think kernfs is a cleaner way to
do things than sysctl is.  UNIX used to be everything's-a-file, or at
least it tried to be.  Things like sockets and sysctl and SysV-style
shared memory introduce additional namespaces which break this; kernfs,
procfs, portal, etc, bring it back.

> Neither one is truly necessary for system operation, although they DO
> appear to be performance treats,

Well...procfs maybe.  kernfs is actually a performance lose when it
comes to small-integer things, because they get converted to strings
(and back, if it's a modifiable thing).  However, it's a small lose,
and is definitely worth it IMO.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu