Re: printk meeting at LPC

[Petr Mladek]

On Mon 2019-09-16 16:28:54, John Ogness wrote:
> On 2019-09-16, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >>>> 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?

/dev/kmsg is one interface passing dictionary. The other is
netconsole. It is the only console with CON_EXTENDED flag set.

> > Then journalctl should work as normal.
> >
> > Or will this break one of our other changes?

It just complicates the code because we need to store and read
the information separately.


> The consoles will just iterate the ringbuffer. So if any console needs
> dictionary information, that information needs to be stored in the
> ringbuffer as well.
> 
> The dictionary text and message text could be stored as concatenated
> strings. The descriptor would point separately to the beginning of
> dictionary and message. So the data-buffer would still be a clean
> collection of text. But AFAIK Linus didn't want to see that "extra" text
> at all.

I would double check with Linus that he would consider this as
breaking userspace.

IMHO, it is perfectly fine to add this support later in separate patch(set) if
really necessary. I can't imagine that anyone would depend on this
feature when bisecting kernel. We could discuss and handle this later.
At least after the merge window.

> If we want to keep dictionary text out of the data-buffer, we could have
> a 2nd data-buffer dedicated for dictionary text. I expect it would not
> really complicate things. Especially if the dictionary part was "best
> effort" (i.e. if the dictionary text does not fit in the free part of
> its data-buffer, it is dropped).

Interesting idea. I like it if it does not complicate the code too much.

Best Regards,
Petr