On Thu, Apr 27, 2006 at 09:15:14AM -0700, Garrett D'Amore wrote:
> Pavel Cahyna wrote:
> > On Wed, Apr 26, 2006 at 11:33:44PM -0700, Garrett D'Amore wrote:
> >   
> >>>  - usr.bin/pmap
> >>>
> >>>     Ugg.  Maybe the worst of the grovellers.
> >>>   
> >>>       
> >> By its very nature, I suspect pmap is going to "want" to have access to
> >> some pretty low level details.  This one might be hard to convert.
> >
> > Is it a good idea to convert it? This would mean to invent a stable
> > interface between the kernel and userland to examine UVM internal data.
> > Later, UVM may change and the interface would not match it anymore. What
> > will you do in this case?
> >   
> 
> Thats the *point* of stable interfaces.  You can change the underlying
> stuff, and as long as there is some stable glue, the programs that
> depend on it won't break.

It seems to me (but I did not study it closely) that pmap is a debugging
tool, which is designed to directly examine the "underlying stuff", not to
provide some abstraction. Look for example at the -D option.

> Otherwise pmap (or whatever) becomes intrinsically tied to the kernel,

Yes. The -D option to pmap for example can dump the process's vmspace
structure (and many other data structures), so it is intrinsically tied to
the mere fact that such structures exist.

> and it is impossible to provide the same kind of information without
> being so closely tied.  This makes it hard for e.g. 3rd party OEMs to
> write programs which work but are not bundled with the kernel.

Do you want to have debugging tools to examine internal data structures of
the kernel implementation, _without_ being closely tied to it? Sorry, that
looks like a contradiction.

Pavel