[lkml]   [2011]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: android logger feedback request
    On 12/21/2011 04:51 PM, Greg KH wrote:
    > On Wed, Dec 21, 2011 at 04:36:21PM -0800, Tim Bird wrote:
    >> On 12/21/2011 03:19 PM, Greg KH wrote:

    > Huh, I'm not talking about syslogd, I'm talking about the syslog(2)
    > syscall we have.

    OK - switching gears. Since the kernel log buffer isn't normally
    used to store use-space messages, I thought you were referring
    to syslog(3) and the associated (logger(1) and syslogd(8)).

    > This character interface seems very close to the syslog(2) api, but just
    > done in a character interface, with ioctls, which also require userspace
    > tools to manage properly, so I fail to see the big "gain" here.
    > What am I missing?

    syslog(2) would more aptly be named klogctrl() (and it is in glibc)

    There's currently no operation in sys_sylog (the kernel function
    implementing syslog(2)) for writing to the log. The write operation
    to the kernel log buffer is also done via a character interface
    /dev/kmsg (via code in drivers/char/mem.c) This is actually very
    similar to what the Android logger code does.

    But while the kernel log buffer has lots of similarities to the Android logger
    there are some key differences which I think are important to isolate
    from a user-space logging system.

    Here's a stream-of-consciousness dump of the differences:

    The printk interface in the kernel is almost always automatically drained
    to the device console, at the time of the printk (after the message is dropped
    into the log buffer itself). This extra operation is not needed for most
    application-level messages that go into the log, and incurs extra overhead
    in the log buffer code.

    The printk code is especially designed to be called from within any kernel
    context (including interrupt code), and so has some locking avoidance code
    paths and complexity that are not needed for code which handles strictly
    user-space messages.

    Oddly enough, the printk code paths in the kernel can end up doing
    a fair amount of print formatting, which can be time-consuming. The code
    path in kmsg_writev() contains at least one kmalloc, which could fail
    when running out of memory. The code path in the logger is much simpler,
    consisting really of only a data copy.

    Timestamping is not automatically appended to messages going into the
    kernel log buffer (but they can be optionally pre-pended, with control
    configurable at runtime). They are represented
    as ASCII text, which consumes a little more than twice the overhead of
    a 32-bit binary field. PID and TID are not automatically preserved in
    the log. The kernel keeps it's priority in text also, and has no convention
    for contextual tagging. I'm not sure that we should change the
    kernel log buffer to support structured binary data, in addition to the
    free-form ASCII data that the kernel uses now.

    The kernel log buffer does not support separate channels for different
    classes of log messages (indeed, there is only one channel, and it has
    kernel messages). A new system call (or some backwards-compatible tweak
    to the existing syslog(2) call would have to be added to support
    a channel ID in order to support this.

    There *are* some benefits to intermingling the kernel log messages and the
    user-space log messages, but I think they are outweighed by the
    value in keeping these systems separate. There might be the opportunity
    for code reuse, but I suspect we'd end up with about the same amount
    of code increase overall (and possibly an additional syscall), and add
    some unneeded complexity to the prink code path to accomplish it.

    I just read Neil Brown's suggestion for doing this via a filesystem rather
    than a char device, and it's interesting. I'll respond to that separately.

    -- Tim

    Tim Bird
    Architecture Group Chair, CE Workgroup of the Linux Foundation
    Senior Staff Engineer, Sony Network Entertainment

     \ /
      Last update: 2011-12-22 02:35    [W:0.038 / U:3.860 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site