Subject: Re: kernel panic messages
To: Martin J. Laubach <firstname.lastname@example.org>
From: Martin Husemann <email@example.com>
Date: 05/04/2003 10:42:25
On Sun, May 04, 2003 at 06:35:09AM +0000, Martin J. Laubach wrote:
> (c) move the actual panic format strings out of the panic call,
> have a char *panic_format_table somewhere and reference just
> the index.
For some reason I can't realy explain I don't like this.
In C++ I would make a panic object that you have to declare a static instance
of, and which enters itself into the panic-string-table. Then panic(9)
would just take a reference to such an object.
Having to manage this global table manually looks unatractive to me.
> (d) make a pass over all strings to make them unique. Rather prone
> to bit-rot since later additions will need another pass in
> a year or so. And another. And...
This is the easiest and fastest solution. We could install a script on
the autobuild machine(s) that tests for uniqueness once a week. I guess
this is the way to go.
Besides that I like Greg's suggestion pretty much. Let me rephrase how I read
- make panic() a macro, maybe going through the tree once to add double
- maybe use proper #ifdef __gcc__ and friends if we somehow end up needing
to use gcc-ism's
- make the macro use __LINE__ and, if available the __KERNEL_RCSID string
- if the rcsid is not available, fall back to either an empty string or
__FILE__, maybe even depending on a kernel compile option.
Now the problem is that the rcsid strings are in .note sections only, and
don't get loaded into the "live" kernel. And I guess we don't want panic(9)
[or the function it eventually calls] have to call the loader to get
additional strings out of the kernel ELF image (which might not even be
This, unfortunately, sounds like an unsolvable problem to me.