• Kay Sievers's avatar
    printk: convert byte-buffer to variable-length record buffer · 7ff9554b
    Kay Sievers authored
    - Record-based stream instead of the traditional byte stream
      buffer. All records carry a 64 bit timestamp, the syslog facility
      and priority in the record header.
    
    - Records consume almost the same amount, sometimes less memory than
      the traditional byte stream buffer (if printk_time is enabled). The record
      header is 16 bytes long, plus some padding bytes at the end if needed.
      The byte-stream buffer needed 3 chars for the syslog prefix, 15 char for
      the timestamp and a newline.
    
    - Buffer management is based on message sequence numbers. When records
      need to be discarded, the reading heads move on to the next full
      record. Unlike the byte-stream buffer, no old logged lines get
      truncated or partly overwritten by new ones. Sequence numbers also
      allow consumers of the log stream to get notified if any message in
      the stream they are about to read gets discarded during the time
      of reading.
    
    - Better buffered IO support for KERN_CONT continuation lines, when printk()
      is called multiple times for a single line. The use of KERN_CONT is now
      mandatory to use continuation; a few places in the kernel need trivial fixes
      here. The buffering could possibly be extended to per-cpu variables to allow
      better thread-safety for multiple printk() invocations for a single line.
    
    - Full-featured syslog facility value support. Different facilities
      can tag their messages. All userspace-injected messages enforce a
      facility value > 0 now, to be able to reliably distinguish them from
      the kernel-generated messages. Independent subsystems like a
      baseband processor running its own firmware, or a kernel-related
      userspace process can use their own unique facility values. Multiple
      independent log streams can co-exist that way in the same
      buffer. All share the same global sequence number counter to ensure
      proper ordering (and interleaving) and to allow the consumers of the
      log to reliably correlate the events from different facilities.
    Tested-by: default avatarWilliam Douglas <william.douglas@intel.com>
    Signed-off-by: default avatarKay Sievers <kay@vrfy.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    7ff9554b
printk.c 48.1 KB