On 9/24/07, Joe Perches <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
