Re: [tlug] Dmesg and CPU Information

[Curt Sampson <cjs@example.com>]

On Mon, 7 May 2007, Stephen J. Turnbull wrote:

> > a bunch of stuff that wouldn't be very interesting unless you were
> > actively debugging that section of the kernel:
>
> Well, *you* (the user) probably aren't, but the responsible developer
> very likely still is nervous about the stuff he fixed before the last
> release. :-)

Yes, but given fifty or sixty people doing that, the dmesg output grows
huge, it becomes impossible find anything, and it rapidly overflows the
message buffer anyway. That way lies madness. It is, to be sure, a fine
line to walk.

> This is one of the things that I hate about the distros: they actively
> go out of their way to make sure that my users can't get information
> about XEmacs crashes. They turn off debugging, strip the symbol
> table, turn off core file generation, split out sources into separate
> packages, etc.

I understand your pain. While I appreciate their wish to keep the
size of packages as small as possible, it would be nice if they'd do
something towards keeping as much debugging capability available as
possible, within reason.

One good approach is to put in debugging code that doesn't run by
default, but can't be configured out of the application, and has simple
flags to turn it on. (Pine does a fairly decent job of this, in at least
some ways.) But I'm sure you have all this figured out already.

> > And the nice, clean, colocated, informative NetBSD output:
>
> That's nice, and way better than Linux's /proc/cpuinfo, to be sure,
> but I still think /proc/cpuinfo is a better place for it if a choice
> is to be made (obviously it could be done in both places).

Actually, for a certain part of it it's quite a bit better to have it
show during the boot process, because if the boot process blows up,
you still have the information. It also provides one place to go for
"the basics," as it were. For new ports, it's quite common for people
to post the dmesg output because it gives an excellent idea of where
the port stands, what it doing and configuring, and so on. And NetBSD
conveniently saves the initial dmesg output to /var/run/dmesg.boot when
it starts the multi-user part of the boot process. The information
also stays available in the memory dmesg buffer, even when booting a
different kernel, if you can manage to reboot without resetting the
machine (which is possible from the debugger).

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974

Mobile sites and software consulting: http://www.starling-software.com