Re: Time to deprecate crash dump support in stats tools (or KVM-grovelers in general)?

[Andrew Doran <ad%netbsd.org@localhost>]

On Sat, Apr 05, 2008 at 12:43:57PM -0700, Jason Thorpe wrote:

> NetBSD has taken great steps recently to modernize its kernel.  One of  
> those steps has been to use per-CPU data for various subsystems (and  
> the list of subsystems employing this technique to gain MP scalability  
> is increasing).
> 
> One of the upshots of moving to per-CPU data is that the data must be  
> collated in order to be reported.  This works well on live systems  
> where sysctl is available.  It doesn't work so well on crash dumps;  
> the tools then have to know the specifics of how per-CPU data is  
> managed for that particular subsystem and collate the data themselves.
> 
> Given this, I think it's time to deprecate crash dump support in these  
> tools (e.g. netstat(1)), and, more generally, deprecate KVM-groveling  
> except in some very specific circumstances.
> 
> Comments?

I fully support removing most of the kvm grovelling stuff. I'm concerned
about what we provide for post mortem debugging though.

We try to include a limited set of debugging symbols for some common
structures into every kernel image, although I don't think that works
properly yet - an i386 GENERIC kernel doesn't seem to contain them. Maybe
we need to tweak the kernel build process a bit?

I can understand the utility of, say, /sbin/dmesg operating on crash dumps,
but a lot of the info we provide through other tools like pstat or netstat
is useless. Random examples: dumping raw unionfs inodes or tcpcb's with a
built in tool seems pointless. Having access to the information in isolation
is nice but it's not much use unless you can go and cross reference it with
other stuff and script up something to mine more information. By and large
the kvm grovellers don't provide that, and we could do better with the
limited debug symbols included in the kernel image.

Cheers,
Andrew