Reviving linux-tiny [LWN.net]

Reviving linux-tiny

Posted Sep 27, 2007 20:33 UTC (Thu) by moxfyre (subscriber, #13847)
In reply to: Reviving linux-tiny by felixfix
Parent article: Reviving linux-tiny

> Why not change all printk to a message number and parameters, and bundle all messages into the source tree only? Waaaay back in mainframe days, you had to look up errors by number for just that reason. I realize it wouldn't be as handy, but for the ones that only developers care about, wouldn't that be good enough? I suppose you could have a build-time option to include the full text, but wouldn't most production system be better off with just a message ID?

I think that's a pretty good idea! For embedded systems, the console is usually a serial port connected to a desktop computer. That computer could run a translator that would simply convert the numeric codes to strings, so the user would see the same thing.

For example, the embedded system might send out a kernel message like:

0xDEADBEEF,/dev/hda,123

... and the translator would convert that to:

<CRITICAL>sata-driver: CRC error on /dev/hda in block 123

Basically, you'd be compressing the kernel by converting human-readable strings to 32-bit numbers. The numbers wouldn't even have to be globally unique! Just unique to that particular kernel build! When you built a kernel for such a system, in addition to a bzImage you would get a Strings.db file. Put the bzImage into the device firmware, and give Strings.db to your serial console translator... voila, ready to debug. This could be a really seamless solution.

(Log in to post comments)

Reviving linux-tiny

Posted Sep 27, 2007 22:25 UTC (Thu) by felixfix (subscriber, #242) [Link]

I hadn't thought of only needing to be unique per build. Interesting idea. You'd lose the ability to google for a universally unique number, but maybe that doesn't matter so much. People who want to read them on a production server or desktop with plenty of RAM would keep the messages themselves in the kernel. It's really only the firmware and other small-footprint people who need to lose the message text.

Reviving linux-tiny

Posted Sep 28, 2007 1:09 UTC (Fri) by moxfyre (subscriber, #13847) [Link]

> I hadn't thought of only needing to be unique per build. Interesting idea. You'd lose the ability to google for a universally unique number, but maybe that doesn't matter so much. People who want to read them on a production server or desktop with plenty of RAM would keep the messages themselves in the kernel. It's really only the firmware and other small-footprint people who need to lose the message text.

Yeah, I think it would be a very useful and not a very complex modification. Store the table of strings on the "big" computer, and just the indices on the "small/embedded" system.

As far as I can tell, it would require a kernel build option to modify printk, and then something to strip the strings out of the object files. Here's a rough sketch of what printk() would look like in this setup: printk() for an embedded system:

#include <stdarg.h>

#define unique_id(string) \
  /* some hash function of the string */

#define printk(format,...) \
  extern const char *__printk_string_ ## unique_id(format) = format; \
  printk_embedded(unique_id(format), __VA_ARGS__, NULL)

void
printk_embedded(int id, ...)
{
  va_list args;
  unsigned int arg;

  va_start (args, id)
  for (arg=id; arg != NULL; arg=va_arg(args, unsigned int))
    kprint_integer_followed_by_comma(arg)
  kprint_char('\n')
  va_end (args)
}

This should work for all printk() argument fields except for strings (since they're not passed by value). And then there would have to be a utility to go through the ELF image and strip out all the __printk_string_XXXXXXXX items... not too difficult I don't think.

There are a few details to work out (how to make string arguments work!!) but otherwise that's about it. Any opinions?

Reviving linux-tiny

Posted Sep 28, 2007 11:54 UTC (Fri) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

If you go down that route, your "message number" could be the address (in hexadecimal) of the string and you instruct the linker/objcopy to remove the ".string" section - plus or minus some special cases.