On 9/24/07, Joe Perches <joe@perches.com> wrote: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). 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 -
| David Miller | Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. |
| Andrew Morton | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Felix von Leitner | socket api problem: can't bind an ipv6 socket to ::ffff:0.0.0.0 |
git: | |
