> 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.
> 
> [sysctl is ugly and depends on header files, kernfs keeps all the
> info in one place]

Oh, don't get me wrong. I'm a big advocate of using the filesystem to
export information from the kernel, and I hate it whenever I see any
other interface (like sysctl) or "namespace" (like sockets, SHM, ...)
that aren't visible to the wealth of unix tools that know how to work
with filesystem objects.

This is supposed to be unix: "everything is a file"

I'd love to see someone come up with a devfs (or /kern/dev) that works
right and addresses all the various problems we've been discussing
here. I'd love to see sysctl move into kernfs and go away (to save
duplicated code).

On the other hand, I know that it takes somebody's time and effort to
do the work, and there are reasonable arguments to be made against
making everything a filesystem in the kernel.  Code size is a
prominent one, I'm also an advocate of keeping as much code out of the
kernel as possible. (Yes, I'm advocating two ideals which conflict,
finding the right tradeoffs is what the game is all about).

My comments above were an observation of a third possibility, which
no-one seemed to have mentioned, that might form the germ of a
practicable solution, or at least allow the possibility to be explored
and rejected based on good technical decisions.

> > 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).

I don't like grovelling kmem either, from an aesthetic viewpoint of
the cleanliness of the interface (and because of the requirement for
so many suid-0 binaries). But, it is the best way to keep out of the
kernel the greatest amount of the code which interprets the kernel
data structures and formats them for the user. If you consider the
interface to be the output of these programs, and that interface is
clean, then it can still be an aesthetically-pleasing solution.

(Sadly, that interface is not so clean and consistent :)

I see kmem grovelling as a special case of a useful "ugly interface".
In a world of ideals, either the kernel should give us a nice
"userland friendly" interface to the data (filesystems being my
preferred one), or userland gives us the interface by grovelling the
data.  Intermediate solutions and extra kernel interfaces somehow (or
at least sometimes) seem to me like the worst of both sides, satisying
neither ideal very well.

--
Dan.

(PS. Pointers to Plan9 are not required, save the bandwidth for
discussions of NetBSD).