Re: [Ksummit-discuss] [TECH TOPIC] printk redesign

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On Tue, 2017-06-20 at 18:27 +0100, Mark Brown wrote:
> On Wed, Jun 21, 2017 at 02:11:34AM +0900, Sergey Senozhatsky wrote:
> 
> > 
> > another thing that I found useful is a CPU number of the processor
> > that stored a particular line to the logbuf.
>
> At some point we start reinventing ftrace...  there's issues with
> joining the two up but there should at least be lessons we can learn.
> 

The other way of looking at this is "why are you abusing printk for
stuff that should have been done via ftrace or other means instead".

I confess I haven't got my curmudgeonly brain out of that mode at all,
ever since realising that printk had been made asynchronous and
unreliable (how long ago was that?) and that you could no longer see
the dying gasp of a crashing kernel on its serial console.

Rather than morphing printk into something more capable of bulk
transport, I'd rather see it go back to its roots of
debugging/diagnostics.

The original complaint of "all this printk output makes things too
slow" was better addressed by printing less or at lower severity (or
adjusting the console loglevel), IMO.

As things stand, the requirements for the various printk (ab)use cases
seem to be contradictory — if we're going to have a redesign then I
think it would be good to take a holistic view and decide what it's
actually *supposed* to be used for. And, perhaps more to the point,
what it isn't supposed to be used for.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]