Reviving linux-tiny

Reviving linux-tiny

Posted Sep 28, 2007 1:09 UTC (Fri) by moxfyre (subscriber, #13847)
In reply to: Reviving linux-tiny by felixfix
Parent article: Reviving linux-tiny

> 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?

---

(Log in to post comments)