Subject: Re: kernel panic messages
To: Martin J. Laubach <>
From: Martin Husemann <>
List: tech-kern
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.