On Sep 20, 2007, at 19:18:41, Rob Landley wrote:That's actually a fairly straightforward problem to solve. Really we ought to be able to guarantee that lines from different CPUs are not intermixed. This can end up in a log like this: info: Current device state: <1>netdev watchdog timeout: eth0 reg1=0xABCD reg2=0xDEADBEEF Clearly unpleasant, no? Really any logging which wants to print out a bunch of stuff with multiple printk()s should use an API something like this: Option 1: Buffer allocated with kmalloc(). Sleep-ish context, can handle failures easily Option 2: Preallocated per-cpu buffer. preempt_disable()d Option 3: Preallocated per-cpu interrupts-only buffer. Only from code which may interrupt a preempt_disable() section For all of the above, the final "qprintk_finish()" call would essentially take the printk spinlock and write the contents of the qpk->buffer into the dmesg ringbuffer, inserting ("<%d>", level) at the beginning and after each newline. The buffers would all be some useful fixed size (a page?); if you need more than that then you are probably trying to queue too much and excess data would be truncated. Since the level would be a constant passed to qprintk_ {kmalloc,percpu,irq} in almost every case, you could easily do something like this: static inline int qprintk_kmalloc(struct printk_queue *qpk, unsigned int level, gfp_t gfp) { if (level > CONFIG_MAX_LOG_LEVEL) { qpk->type = QPRINTK_TYPE_NONE; /* also 0 */ qpk->buffer = NULL; return 0; } _qprintk_kmalloc(qpk, level, gfp); } #define qprintk(QPK, FMT...) do { \ if ((QPK)->type) _qprintk(QPK, FMT); } while(0) With a bit more glue that would cause GCC to notice that for a given qprintk_kmalloc the "qpk->type" is always zero because the level is too high, and therefore it would optimize out *ALL* of the _qprintk_kmalloc(), _qprintk(), and _qprintk_finish() calls. Cheers, Kyle Moffett -
| 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 |
