[[!meta copyright="Copyright © 2010, 2013, 2014 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!meta title="AF_BUS, D-Bus, and the Linux kernel"]]

Might be interesting to watch how this develops.

[[!toc]]


# IRC, freenode, #hurd, about 2010-08/2010-09

    <neal> check this out:
    <neal> someone is working on implementing dbus in linux
    <neal> linux finally gets mach ipc ;-)
    <marcusb> it's old news though, unless there is an update
    <marcusb> and I think it was only the client?
    <neal> youpi : someone is adding dbus ipc to the linux kernel
    <neal> marcusb: I just heard about it.
    <youpi> (it's crazy how this drives backward compared to a hurdish approach)
    <youpi> what is the motivation for moving to the kernel?
    <neal> context switch overhead
    <azeem_> they wanna use it to talk to device drivers? :)
    <kilobug> well, they did that with the in-kernel web server, but they
      abandonned it later on
    <neal> azeem: I don't think so.
    <neal> dbus in the kernel is actually good for the Hurd as dbus IPC is
      basically neutered Mach IPC
    <marcusb> I don't think anybody wants to put the dbus server in the kernel
    <neal> well, there is at least one person
    <marcusb> maybe this is a different news from the one I read
    <neal> Alban Crequy (albanc) is working out.  He works for collabora, fwiw

<http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/>

    <marcusb> what I read was about hal etc
    <marcusb> so that you don't need a user space daemon to glue the kernel to the
      dbus world
    <neal> I don't think that is what he is talking about
    <marcusb> I can't find it anymore though.  I mentioned it in this channel at
      the time though, so it should be in the backlog
    <marcusb> neal, yeah could very well be a separate thing
    <marcusb> neal, dbus does have marginal support for fd passing though, and some
      attempts on the mailing list to make "fds" an official type in the message
      failed (as far as I could see, I didn't read the whole discussion)
    <marcusb> so no mach ipc just yet
    <neal> wrong
    <neal> FD handling is in 1.4
    <neal> type o, if I'm not mistaken
    <marcusb> then the discussion moved on from initial rejection
    <neal> no, 'h'
    <marcusb> I'm out of date by two months
    <marcusb> ok
    <guillem> neal: AFAIR Marcel Holtmann talked about dbus in-kernel several years
      ago, but he never ended up implementing it, or there were rumors he had
      private "working code"

  * Related Mailing List Discussion

      * [\[PATCH 0/5\] RFC: Multicast and filtering features on
        AF_UNIX](http://article.gmane.org/gmane.linux.kernel/1040481),
        2010-09-24


# 2013-02

[AF_BUS, D-Bus, and the Linux
kernel](http://www.kroah.com/log/linux/af_bus.html), Greg Kroah-Hartman,
2013-02-08.


# kdbus


## IRC, freenode, #hurd, 2014-01-28

    <braunr> i would like to see things like dbus and zeromq use an optimized
      microkernel transport one day
    <teythoon> we could port kdbus >,<
    <braunr> why not
    <braunr> you port cgroups first
    <teythoon> exactly
    <braunr> :p

[[systemd]].


## IRC, freenode, #hurd, 2014-02-23

In context of [[linux_as_the_kernel]], *IRC, freenode, #hurd, 2014-02-23*.

    <desrt> mach seems like this really simple thing when you first explain
      what a microkernel is
    <braunr> and because of that, i think it's better to start the right
      solution directly
    <braunr> it looks simple, it's clearly not
    <desrt> but i did a bit of looking into it... it's a bit non-trivial after
      all :)
    <braunr> mach ipc is over complicated and error prone
    <braunr> it leads to unefficient communication compared to other solutions
      such as what l4 does
    <desrt> ya -- i hear that this is a big part of the performance hit
    <braunr> that's why i've started x15
    <desrt> i was also doing some reading about how it's based on mapping
      memory segments between processes
    <braunr> first, it was a mach clone, but since i've come to know mach
      better, it's now a "spiritual" mach successor .. :)
    <desrt> these are two issues that we've been dealing with at another
      level... in the design of kdbus
    <braunr> ah kdbus :)
    <desrt> this is something that started with my masters thesis a long time
      ago...
    <braunr> ah you too
    <desrt> first thing we did is make the serialisation format so that all
      messages are valid and therefore never need to be checked
    <desrt> (old dbus format requires checks at every step on the way)
    <braunr> looks interesting
    <desrt> then of course we cut the daemon out
    <desrt> but some other interesting things: security is super-simple... it's
      based enirely on endpoints
    <desrt> either you're allowed to send messages between two processes or
      you're not
    <desrt> there is no checking for message types, for example
    <braunr> yes
    <desrt> and the other thing: memory mapping is usually bad
    <braunr> that's what i mean when i say mach ipc is over complicated
    <braunr> it depends
    <desrt> the kdbus guys did some performance testing and found out that if
      the message is less than ~512k then the cost of invalidating the TLB in
      order to change the memory mapping is higher than the cost of just
      copying the data
    <braunr> yes, we know that too
    <braunr> that's why zero copy isn't the normal way of passing small amounts
      of data over mach either
    <desrt> nice
    <desrt> i got the impression in some of my reading (wikipedia, honestly)
      that memory mapping was being done all the time
    <braunr> well
    <braunr> no it's not
    <braunr> memory mapping is unfortunately a small fraction of the
      performance overhead
    <desrt> that's good :)
    <braunr> that being said
    <braunr> memory mapping can be very useful
    <braunr> for example, it's hard for us to comply with posix requirements of
      being able to read/write at least 2G of data in a single call
    <braunr> weird bugs occur beyond 512M iirc
    <braunr> you do want memory mapping for that
    <desrt> ya... for things of this size.... you don't want to copy that
      through a socket :)
    <braunr> monolithic kernels have it naturally, since the kernel is mapped
      everywhere
    <braunr> for microkernels, it's a little more complicated
    <braunr> and the problem gets worse on smp
    <braunr> again, that's why i preferred starting a new kernel instead of
      reusing linux