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

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> [In another message, der Mouse has concerns about gdb scripts vs kvm
> grovelers.  Joerg Sonnenberger followed with comments about
> duplicated code and how GDB was a huge win in his opinion.]

> I'd echo der Mouse's comments/concerns.  I don't see how trading C,
> which maybe non-trivial, for non-trivial GDB scripts is a win.  If
> the C is truly duplicated then maybe it needs to live in a common
> place like libkvm.

Well, there is a legitimate concern lurking, that being that the kmem
groveling code be kept with the kernel sources rather than being
scattered through userland (ccdconfig, pstat, dmesg, iostat, ps, etc).

However, I see no reason addressing that requires writing the grovelers
in gdb rather than C.  (Using centralized C code semi-compels output
formats unlike the live-kernel tool, but gdb scripts have that same
problem, if problem it be.)

> Or is the concern that code is duplicated between the kernel and
> user-space code?

That's just as true of gdb scripts as of C code.

> Why tie analysis to GDB?  What happens when we want to go to
> abbreviated/sparse dumps because it is no longer practical to dump
> multi-gigabyte kernel core images?

That's an issue for kernel gdb of any sort, not just written-in-gdb
kmem grovelers.  I'd be more concerned about what happens with new
versions of gdb - as far as I can tell its scripting language is not a
defined interface and thus cannot be counted on to remain stable from
version to version - and the use of a little-known and badly-documented
language rather than a well-known and thoroughly-documented one.

> Also how are the C code, as in netstat(1), and the GDB scripts going
> to be kept in sync?

That's a reasonable concern with pulling the code out and keeping it
with the kernel.  Personally, I think it's more important to keep it in
sync with the kernel than it is to keep it in sync with the live-kernel
tools that display the same basic information.

One possible alternative would be to actually put the code in the
kernel, with care taken so that it can be called out of an mmap()ed
kernel image with a kernel core.  (The easiest way would be to use a
pcode engine, but then we're back to a little-known language.  At least
it would be our own, rather than under third-party control, but it
still raises many of the concerns gdb scripts do.  Maybe a backend for
our C compiler to generate the pcode?  That might well be more work
than it's worth.)

> Ideally don't you want them to both display the information in the
> same way?

Ideally, sure.  But that has costs, and the cost of maintaining the
kmem grovelers as part of the live-kernel tools is proving problematic.
I think at least trying the tack of maintaining them as
kernel-associated tools instead (whether written in gdb or C or
whatever) is reasonable.  We can always switch back if the costs turn
out higher that way.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B