> This is true, but "what is appropriate"?

> There's absolutely nothing that you can do to remove the libkvm
> interface.  Most things that use it are designed to operate on dead
> kernels as well as live ones, and there's no a way a kernel core
> dump is going to provide a "procfs" interface.

I'd like to point out that Charles's proposal for extending sysctl
would solve this problem.  The idea is to unify all informational
kernel queries into the sysctl interface() and set up the relevant
kernel data structures so that a library can grovel through a kernel
core dump.  You wind up with a small amount of logic duplicated in the
kernel and user-space, and save a lot of code currently dedicated to
performing a bunch of different filesystem queries.

The debate over Charles's proposal stalled over the atomicity of his
proposed interface, which was to be patterned after SNMP ("Aagh!  I
said it!  Aaghh!  I said it again!  Aagh..."), since the kernel
currently provides atomic snapshot routines for certain queries (or at
least, that was someone's claim) and SNMP's iterator design doesn't
allow for atomicity.  There were also concerns over having to do a lot
of extra system calls to retrieve a table.  It may be that we want to
extend the proposed SNMP-like interface to include dumping snapshots
into a buffer.

Anyway, I just wanted to point out that there is an alternative to
procfs here, although it's a lot of work.  Filesystem interfaces are
pretty expensive.