[lkml]   [2011]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/11] RFC: KBUS messaging subsystem
    On 17 May 2011, at 09:50, Florian Fainelli wrote:

    > Hello,
    > Sorry for this late answer.

    Not a problem from here, all responses are helpful. In, turn, apologies
    for taking so long to reply.

    > Most implementations (if not all) involving system-wide message
    > delivery for other daemons are running in user-space.

    OK. Although I certainly wouldn't claim to have anywhere near a complete
    list of such (an annotated list of all the messaging systems on Linux
    would be rather interesting, though!).

    > If you had in mind that this daemon might be killed under OOM
    > conditions, then maybe your whole system has an issue, which
    > could be circumvented by making sure the messaging process gets
    > respawned when possible (upstart like mechanism or such).

    OOM isn't particularly an issue I'd worried about for any part of the
    system. Other things tend to cause user processes to crash - using
    ffmpeg on random video data, for instance. Of course, that is clearly
    not a problem for KBUS itself.

    Respawning itself isn't directly a problem, but getting everyone talking
    to everyone else again is typically a nasty pain (and one users don't
    want to think about), so one tends to want one's messaging handler to be
    *very* robust. I think the discipline of working in-kernel helps with
    that, although I'd be surprised if that were considered enough reason to
    add a new kernel module!

    > From: Jonathan Corbet <>
    > Date: 22 March 2011 19:36:40 GMT
    > > Even better might be to just use the socket API.
    > Indeed, I would also suggest having a look at what generic netlink already
    > provides like messages per application PID, multicasting and marshaling.

    As I said in an earlier message, I'd ignored netlink because it sounded
    as if were intrinsically losssy (no way of not losing messages if a
    queue got full) which is a problem for KBUS requests/replies.

    On the other hand, understanding netlink from scratch is somewhat
    difficult (I've just spent some hours doing more research, and don't
    feel like I've begun to get a good idea of its boundaries yet).

    I have also been reading the libnl documentation, which seems to make
    the userspace end somewhat less complex, and looks like a good thing.

    > If you intend to keep a part of it in the kernel, you should have a
    > look at this, because from my experience with generic netlink, most of
    > the hard job you are re-doing here, has already been done in a generic
    > manner.

    It looks interesting, but the worrying part of statements like this is
    always the "most of".

    Is your suggestion that netlink would be a better API than the current
    "creating" use of a file API for communicating from user space to the
    KBUS kernel module, and then back?

    The LWN article makes that sound
    plausible (assuming one can still detect "release" events for netlink
    sockets - I assume one can). At first glance I'm not sure how much
    harder it is to program such a netlink interface "bare" (without a
    userspace library such as libnl) than it is to use the current KBUS
    interface in such a manner.

    (Aside: a quick look at my current KBUS build shows kbus.ko as 60KB, (the C userspace library on top of the "raw" usage) as 54KB,
    and as 277KB - although I don't know how Ubuntu build the
    latter, and it obviously also includes all sorts of data description
    handling which KBUS deliberately does not. So netlink smaller if "bare",
    and bigger, but not a huge amount, if used with its library.)

    I'm not entirely sure what happens if either end of the netlink API
    doesn't respond in a timely manner - is netlink allowed to throw things

    Or did you mean that netlink is appropriate to replace some/much of the
    KBUS kernel module as well? In that case I'd have to think about it a
    lot more to have an informed opinion.


    What I'm working on at the moment is an email in which I try to restate
    what we are/were trying to do with KBUS, with simple examples of the
    sorts of call we're talking about, and ask if that is a sensible thing
    to have in the kernel, emphasising that we are more worried about the
    functionality than the API.

    If the concept is a good thing but our implementation of it is
    objectionable (e.g., we need to rewrite to a less "creative" interface,
    be more sockety, or whatever), then so be it, we'll need to rewrite.

    If you'd be willing to look at that email when it is posted, I hope it
    will be easier to point at specific things and say "yes, that would be
    better done with netlink" or, perhaps, "netlink would not address this,
    but one might attack it in this way".


     \ /
      Last update: 2011-05-22 22:01    [W:0.025 / U:14.092 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site