On Thursday 20 September 2007 4:58:54 pm Tim Bird wrote:Hmmm. The hard part isn't making printk(0,blah) mean the same as not having a log level message now, because the current logic already handles it. The problem is that filtering continuations of previous messages involves knowing what log level the previous message was so you know whether or not to filter it. Yeah, that would take some doing to untangle. An incremental switchever (easy printks first, I.E. the ones that currently specify a loglevel) seems more strongly indicated... That said, I started this by noting I haven't personally had time to bang on this since I thought of it. You did ask for ideas. :) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -
| 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 |
