To take your points in reverse order, Jason:

> 	(b) We'd have to keep the kmem interface anyhow, because
> 	    we don't want to give up looking at kernel port-mortems.

I don't know that this counts a a strike against /kern and /proc,
since I would never propose giving these up, anyway. It's handy to
be able to look at any variable in the kernel one wants to. (Although
once a Linux fellow seemed to be claiming that you can indeed get
the value of and change any global kernel variable through their
/kern filesystem.)

> 	(a) In order to use them, it requires people to load up
> 	    their kernels with kernfs and procfs.  This is bad,
> 	    particularly in an "embedded" application.  For example,
> 	    we have a couple of NetBSD IPv6 routers here, and the
> 	    kernels are lean, but being able to use iostat and
> 	    vmstat is good.

Would it bloat terribly if we included the ability to do both in
these utilities (or #ifdef'd them)? I'm sure that there are people
out there regularly recompiling kernels that don't have the time
and space to do the whole userland too who would be happy to have
a userland that didn't need updates so often.

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.