On Thu, 9 Jan 1997, Daniel Carosone wrote:

> Well, I see a third possibility - replace MAKEDEV with a program that
> grovels kmem and pulls out all the info that you'd like to put in a
> devfs. Or even have the kernel produce a nice tree structure via some
> new interface that doesn't have all the overhead of a vfs layer. Then
> populate a normal plain ffs.

What's wrong with a vfs layer, besides the fact it must be written? One
big advantage a vfs layer would have over other ways of getting info out
of the kernel is that it can export info very cleanly to user-land.

By that I mean that when ever you change a kernel, you don't have to
re-compile ps or w or a library, nor have the running kernel be accessable
(as /netbsd). Also, you have all the info in one place. As I understand
sysctl, the hierarchy of all the names lives in the include files. The
kernel doesn't know what the different parameters are called, it just
knows a train of integers, and looks in tables for what those integers do.
If the table and the include file (or the current table and the include
files when sysctl were compiled) differ, you're hosed.

One of the things I like about kernfs is that the table describing things
is: { "Item name to export", &thevariable, flag-for-what-data-type}. Since
everything's in one place, it's harder (though not impossable!) for things
to get out of sync.

So what does this defense of vfs have to do with the current thread? I'm
not sure. I agree that the user (well, super-user) should be able to
re-name things, and there should be some way to preserve such info across
boot.

Maybe either something like quotas (where the is a quota file living on an
fs which stores info used by the kernel), or we could add symbolic major
#'s. For instance, we don't at present use major #'s less than 0 (do we?),
so maybe we could assign numbers (unique across all ports) for device
types, and have the kernel re-map them to correct, local values.

The idea is we take a space of major #'s which we won't use (over 10000
would work if they are unsigned), and add a column to the cdev or bdev
tables indicating that this entry is symbolicly device X. When given such
a number, the kernel scans the symbolic name field of each element, and
replaces the symbolic major # with the correct major #.

> Almost, but not quite, like the solaris "drvconfig, devlinks, .."
> programs, at least in concept.
> 
> Lets you use the kernel information, without putting the code in the
> kernel.

I must admit I really don't like kernel munging. Well, I think if a user
program needs info, the kernel should export it cleanly unless there's a
good reason not to (like the process table access for ps; I agree it
shouldn't move around via sysctl calls as was discussed quite a while back
on teck-kern, but maybe the kernel address and ps table version COULD be
exported).

Hmm. Looks like that's my four cents for the day. :-)

Take care,

Bill