Re: [RFC] New kernel-message logging API

["Vegard Nossum" <vegard.nossum@gmail.com>]

On 9/24/07, Joe Perches <joe@perches.com> wrote:
> On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote:
> > Together with the idea of not allowing multiple lines in the kprint_xxx
> > functions, that would go with our approach having message numbers to
> > identify a message.
>
> How does this equate/give message numbers?

Storing the format-string separately allows us to hash THAT instead of
the formatted (ie. console output) message. Since this will never
change from message to message, it can be looked up in a table or
whatever and allow user-space to do translations without for example
regular expressions.

I'm pretty sure this *would* be possible to do with existing printk(),
but I'm betting it also wouldn't look very nice (i.e. hackery).

> > If you do it like that, you can't support "%s", since then you would
> > store only the pointer and not the whole string. I think, that we can't
> > live without %s.
>
> long long would not work either.
>
> Perhaps it's better to scan the format string or indirect the
> printk formatting logic.

The idea was to not use snprintf() for the stored message, but have a
printf-like function that instead writes the output of each format
specifier to its own string (ie. each argument produces a new char*
object). Also needed would be an additional function that reads the
format string but uses the stored arguments.

This turned out to be slightly harder than I assumed at first, though
it's of course not impossible. The downside of this approach is of
course the need to maintain normal vsnprintf() and new functions side
by side, with little possibility of reusing the format parsing of
vsnprintf().

I will follow up with some code to demonstrate as soon as I can.


Vegard