[lkml]   [2011]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: android logger feedback request
    On Thu, Dec 22, 2011 at 03:12, Tim Bird <> wrote:
    > On 12/21/2011 05:47 PM, Greg KH wrote:

    >> Again, please see what we are already doing in the kernel and userspace,
    >> I think a lot of the above is already implemented.
    > I don't know what systemd has got going on in user-space.  I'm looking
    > at a very recent kernel, and I see no support for multiple log channels,
    > or an optimized open/write path.

    > How does current systemd prevent user-space messages from crowding
    > out kernel messages?  (or vice-versa).

    It intentionally doesn't. Splitting messages in separate stores is not
    what we want in the general use case.

    Syslog has the 'facility' for that, and it works just good enough. We
    think that filtering in the receiver is more flexible and useful, than
    to have multiple stores of pretty much the same type.

    If you have multiple stores, you always have to fight the ordering
    problem, and that really creates problems sometimes.

    We are very convinced, that there should be a single entry only for
    logging, and not multiple, and the filtering should happen on the
    receiver side.

    > Since you've been doing
    > a lot of work on logging, do you have any existing metrics for logging
    > overhead via the kernel log buffer?

    Which overhead? I don't really think that is too interesting. Writing
    to a device node or socket and copy it to the kernel's ring buffer,
    not sure if it has an interesting potential of being optimized, if you
    don't use fancy consoles and such.

    We have no numbers, but until I see numbers of a real world problem, I
    would expect there is no actual problem.

    >> Which brings me back to my original question, what does this code do,
    >> that is not already present in the kernel, and why is a totally new
    >> interface being proposed for it?
    > At the least, it supports multiple log channels.  Quite frankly my mind
    > has been blown a bit by the suggestion to overload the kernel log buffer
    > with user-space messages.  I would never have gone that route. But I'll have
    > to find out more about this systemd thing to answer your question.

    It's just fine. And honestly, for early boot and debugging
    interleaving is exactly what you want, because userspace is triggering
    the actions in the kernel, and you want to see that in the same

    Also you can use netconsole and all the weird stuff people support for
    the kernel and get the messages from early boot userspace including
    intramfs there.

    > Secondly, this is not a particularly new or radical interface. It is new
    > to legacy Linux, but it's been in the Android Linux kernel for some years
    > now, and it has worked well.

    Sure, it's understandable, it sounds like something that made sense
    when it was invented, and which probably still make a lot of sense for
    Android today. But I don't think it should be discussed as a general
    purpose Linux use case, or something that replaces kmsg. It does not
    look like too interesting for general needs today outside of Android.

    We probably just want the simple stuff we have today, or something
    that really solves the structured logging problem in a proper way.
    Something slightly better, with almost the same model and limitations,
    than what we have already, is probably not that important enough to
    make changes.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-12-22 04:47    [W:0.025 / U:17.380 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site