> There's also the problem that if you unify _all_ informational
> queries into this one interface, the interface must provide the full
> generality of libkvm.

There's no reason why kvm_open() and kvm_nlist() would have to go
away.

> I think my point is: there exist situations in which libkvm is
> _very_ useful, and hard to replace.  There also exist situations
> where people don't need or _want_ to pay the cost of 'procfs,' or
> some 'unified interface.'

As I noted in my mail, unifying kernel queries under sysctl() is
intended to reduce the amount of code in the kernel (by eliminating
specialized code for walking through data structure), not increase it.
If you disagree that this is possible, you should say so before
assuming it in your arguments.

File system interfaces like /procfs are expensive in terms of the
amount of kernel code needed and the time taken to perform operations.
But there's no need to assume that a more "correct" implementation of
ps and other utilities will consume more wired kernel memory.  As a
simple example (this is another one of Charles's ideas), if you don't
build your kernel with DDB, instead of discarding the symbols passed
in by the boot loader, the kernel could mark those pages pageable and
allow user-space to access those pages somehow.  Then kvm_nlist()
could read the in-core symbols, rendering /netbsd unnecessary for ps
(although ps would still break if the proc structure changes).