Thread (17 messages) 17 messages, 8 authors, 2019-10-07

Re: printk meeting at LPC

From: Petr Mladek <pmladek@suse.com>
Date: 2019-09-16 10:46:30

Possibly related (same subject, not in this thread)

On Mon 2019-09-16 13:30:17, Tetsuo Handa wrote:
On 2019/09/13 22:26, John Ogness wrote:
quoted
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.

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.

quoted
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.

Best Regards,
Petr
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help