lkml.org 
[lkml]   [2019]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: printk meeting at LPC
    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.


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


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

    \
     
     \ /
      Last update: 2019-09-16 12:46    [W:4.178 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site