Messages in this thread | | | From | Kay Sievers <> | Date | Tue, 3 Apr 2012 05:00:10 +0200 | Subject | Re: [PATCH] printk(): add KERN_CONT where needed |
| |
On Tue, Apr 3, 2012 at 04:36, Joe Perches <joe@perches.com> wrote: > On Tue, 2012-04-03 at 03:18 +0200, Kay Sievers wrote:
>> hpet0: at MMIO 0xfed00000, IRQs >> 2 >> , 8 >> , 0
> You are going to find many, many _hundreds_ of these.
Yeah, and they should all be fixed over time. It's 2012 and time to make kernel log messages readable for machines, not for humans to puzzle them together. :)
> Maybe it'd be better to aggregate content rather like > printk does. Aggregate until you get a newline or a > new KERN_<LEVEL>
The continuation printk() can can always go wrong when multiple threads do that in parallel. We can try to make it better with a per-cpu buffer, but I guess there will always be a situation where this can happen.
I'm confident, that only callers who are willing to take that 'risk' of interleaved messages should be exposed to the problem, and never ones who print proper single lines.
In other words, we should guarantee that there is no garbage left from any earlier printk() for someone who does not want to play this continuation print() game.
> A couple of other trivial comments: > > It's better to try to coalesce multiple printks(KERN_CONT > (perhaps it's better to use pr_cont instead too) > > Branches with the same printks should be hoisted where > possible.
Sure, please send patches for anything that is more appropriate to use here.
I did not want to change any logic which needs to be tested. I just trivially added the obviously missing prefix, which solved the problem, and which could be applied right away.
Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |