On Mon 2019-09-16 16:28:54, John Ogness wrote: > On 2019-09-16, Steven Rostedt <rost...@goodmis.org> 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
