Re: printk meeting at LPC

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 16 Sep 2019 12:46:24 +0200
Petr Mladek <pmladek@suse.com> wrote:

> On Mon 2019-09-16 13:30:17, Tetsuo Handa wrote:
> > On 2019/09/13 22:26, John Ogness wrote:  
> > > 6. A new may-sleep function pr_flush() will be made available to wait
> > > for all previously printk'd messages to be output on all consoles before
> > > proceeding. For example:
> > > 
> > >     pr_cont("Running test ABC... ");
> > >     pr_flush();
> > > 
> > >     do_test();
> > > 
> > >     pr_cont("PASSED\n");
> > >     pr_flush();  
> > 
> > Don't we need to allow printk() callers to know the sequence number which
> > the printk() has queued? Something like
> > 
> >   u64 seq;
> >   pr_info(...);
> >   pr_info(...);
> >   pr_info(...);
> >   seq = pr_current_seq();
> >   pr_wait_seq(seq);
> > 
> > in case concurrently executed printk() flooding keeps adding a lot of
> > pending output?  
> 
> My expectation is that pr_flush() would wait only until the current
> message appears on all consoles. It will not wait for messages that
> would get added later.

Right, I believe we agreed that pr_flush() would take care of all this.

> 
> 
> > By the way, do we need to keep printk() return bytes like printf() ?
> > Maybe we can make printk() return "void", for almost nobody can do
> > meaningful things with the return value.  
> 
> It is true that I have never seen anyone checking the return value.
> On the other hand, it is a minor detail. And I would prefer to stay
> compatible with the userland printf() as much as possible.

I understand your wanting to keep compatibility with printf(), but I
would suggest that we only do so if it doesn't complicate any of the
design. I'm actually leaning on recommending that we remove the return
value, to prevent there becoming a dependency on it. I don't see any
reason to have the "number of bytes processed" as the return value
being useful within the kernel.

> 
> 
> > > 9. Support for printk dictionaries will be discontinued. I will look
> > > into who is using this and why. If printk dictionaries are important for
> > > you, speak up now!  
> > 
> > I think that dev_printk() is using "const char *dict, size_t dictlen," part
> > via create_syslog_header(). Some userspace programs might depend on
> > availability of such information.  
> 
> Yeah, but it seems to be the only dictionary writer. There were doubts
> (during the meeting) whether anyone was actually using the information.
> 
> Hmm, it seems that journalctl is able to filer device specific
> information, for example, I get:
> 
> $> journalctl _KERNEL_DEVICE=+usb:2-1  
> -- Logs begin at Tue 2019-08-13 09:00:03 CEST, end at Mon 2019-09-16 12:32:58 CEST. --
> Aug 13 09:00:04 linux-qszd kernel: usb 2-1: new high-speed USB device number 2 using ehci-pci
> 
> One question is if anyone is using this filtering. Simple grep is
> enough. Another question is whether it really needs to get passed
> this way.
> 

If worse comes to worse, perhaps we let the console decide what to do
with it. Where all consoles but the "kmsg" one ignores it?

Then journalctl should work as normal.

Or will this break one of our other changes?

-- Steve