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
it:

 - make panic() a macro, maybe going through the tree once to add double
   paranthesis
 - 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
available).

This, unfortunately, sounds like an unsolvable problem to me.

Martin