Rob Landley wrote:... I agree in principal with the idea, but there are some major practical wrinkles that would have to be worked through. First, not all printks that are missing a log level should have one. People do stuff like this: printk(KERN_INFO "interesting info follows:"); ... printk("var5: %d\n", var5); Or even things that evaluate to: printk(""); The code inside printk currently has to examine the strings, looking for line feeds and inserting log levels. Given that there are about 60,000 printks in the kernel (and that's not counting wrappers like dprintk() and other locally-defined functions and macros) it would be a huge task to examine the code and differentiate strings that really start a new log message (and thus should have an attached log level) and strings that don't. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= -
| Arnd Bergmann | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| Andrew Morton | 2.6.23-rc1-mm2 |
| Nick Piggin | [patch 3/6] mm: fix fault vs invalidate race for linear mappings |
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Herbert Xu | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| David Miller | Re: [BUG] New Kernel Bugs |
