[tlug] Dmesg and CPU Information

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > If they can agree on Kernel API changes, I'm sure they could agree on
 > what kind of messages things print.

Actually, my experience is that messages are one of the areas that
it's hardest to get agreement on.

 > Anyway, Linux kernel development, in and of itself, seems
 > reasonably centralized, even if there are eighteen zillion
 > different userlands.

In the sense that everything eventually goes through Linus, it is.
But Linus is pretty laissez-faire about things like this:

 > 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. :-)

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'm not surprised that developers of a consumer-
oriented kernel prefer to leave debug messages in there long after
developers who expect a rather large fraction of their users to be
building their own do.

 > 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).