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

[Andrew Lunn <andrew@lunn.ch>]

On Wed, Jun 21, 2017 at 02:23:04PM +0200, Petr Mladek wrote:
> On Tue 2017-06-20 19:28:58, Steven Rostedt wrote:
> > I've thought about this a little too.
> > 
> > I would like printk to have per-cpu buffers. Then we don't even need to
> > store the CPU number, that would be explicit by which buffer the data
> > is stored in.
> > 
> > The one thing that is needed, is the consumer. In ftrace, it's whatever
> > reads the buffer, which is usually user space, but can be the kernel
> > (see sysctl-z). But there's only one consumer at a time.
> > 
> > I was thinking about a new design for printk. Similar to ftrace, but
> > different.
> > 
> > 1) have per cpu buffers, that are lockless. Writes happen immediately,
> > but the output happens later.
> 
> My problems with per-CPU buffers is that:
> 
>     + I am not sure how big per-CPU buffers we could afford.
>       Any non-balanced usage increases the chance of loosing
>       messages.
> 
>     + The information is scattered and extra tools are needed
>       to locate the messages and sort them.

Considering this from the Embedded world, during board bring up, you
might be poking around in memory using a JTAG interface because your
serial driver is not working yet, or the kernel is crashing before the
serial port is up and running. The in-memory format needs to be quite
simple to read. I don't know how early_printk() factors into
this. Maybe that solves this problem?

      Andrew