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

[Petr Mladek <pmladek@suse.com>]

On Wed 2017-06-21 16:18:08, Andrew Lunn wrote:
> 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?

Early printk just directly writes the messages on an early console.
They are not stored anywhere.

Best Regards,
Petr