Subject: Re: kernel & libkvm [was IIci success]
To: Greg Hudson <ghudson@mit.edu>
From: None <Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU>
List: current-users
Date: 01/12/1996 20:01:29
> > 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.

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.

If it doesn't, then it becomes much harder to use a large set of
debugging techniques that involve reading mem/kmem.  (for instance,
the other day i noticed that a data structure was being corrupted in
the kernel.  I wrote up a little program to peer into kernel memory,
so that i could manually diagnose the problem.)  Unless the 'unified
interface' supports the full libkvm generality, then this would no
longer be possible.


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

I've no real objection to, say:
	(1) having somebody clean up procfs so that it works well
	    enough to be used in place of libkvm for many things,	   
	(2) having somebody clean up the interfaces used to extract
	    'standard' sets of data from the kernel, so that they
	    could be used witha procfs,

as long as the implementation was done so that procfs was unnecessary
for proper operation.

I don't mind paying 20k, or even 200, in a shared library or in a few
binaries to allow ps to use procfs where appropriate, etc.  I _do_
mind being forced to pay it, in wired memory in the kernel, to get
standard system functionality like 'ps.'



chris