Re: [PATCH] printk(): add KERN_CONT where needed

[Kay Sievers]

On Tue, Apr 3, 2012 at 04:36, Joe Perches <joe@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/