[ On Sun, September 13, 1998 at 20:06:49 (-0400), Perry E. Metzger wrote: ]
> Subject: Re: /kern/kernel 
>
> I think the only solution here is to come up with a library for doing
> the kernel memory grovelling that works just as well in a
> procfs/kernfs/sysctl universe as in a dead kernel universe. Someone
> clever can perhaps come up with a way to do this. It is okay if it
> means having the same .c file used by the kernel and by some library,
> but it is not a good thing if it means having the kernel and userland
> duplicate code somehow.

I don't think that's the only solution at all.

I think the best solution here would be to augment the existing GDB
scripts to an extent that they are as good or better than any other tool
for grovelling in core dumps and to then switch all run-time kernel
access (i.e. libkvm) to use kernfs or whatever it might be called.

Holding on to the "ancient mud pit", as Mr. Elz so eloquently put it,
just because some systems programmers find it convenient to use
user-land tools to examine crash dumps is a rather sad state of affairs,
esp. when it should be reasonably easy to enhance an already good crash
analysis environment to the point where existing user-land tools would
be redundant at best.

BTW, there are several extremely good reasons for having the kernel do
the work of creating easily parsable ASCII output instead of trying to
maintain the formatting in user-land tools.  The only valid objection
I can think of might be that it adds too much bloat.  One might read
some of the Plan 9 papers for inspiration if you don't agree.  Of course
given the anti-bloatedness of Plan 9 one might wonder just how much
bloat ASCII formatting could possibly add.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>