[[!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 check this out: someone is working on implementing dbus in linux linux finally gets mach ipc ;-) it's old news though, unless there is an update and I think it was only the client? youpi : someone is adding dbus ipc to the linux kernel marcusb: I just heard about it. (it's crazy how this drives backward compared to a hurdish approach) what is the motivation for moving to the kernel? context switch overhead they wanna use it to talk to device drivers? :) well, they did that with the in-kernel web server, but they abandonned it later on azeem: I don't think so. dbus in the kernel is actually good for the Hurd as dbus IPC is basically neutered Mach IPC I don't think anybody wants to put the dbus server in the kernel well, there is at least one person maybe this is a different news from the one I read Alban Crequy (albanc) is working out. He works for collabora, fwiw what I read was about hal etc so that you don't need a user space daemon to glue the kernel to the dbus world I don't think that is what he is talking about I can't find it anymore though. I mentioned it in this channel at the time though, so it should be in the backlog neal, yeah could very well be a separate thing 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) so no mach ipc just yet wrong FD handling is in 1.4 type o, if I'm not mistaken then the discussion moved on from initial rejection no, 'h' I'm out of date by two months ok 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 i would like to see things like dbus and zeromq use an optimized microkernel transport one day we could port kdbus >,< why not you port cgroups first exactly :p [[systemd]]. ## IRC, freenode, #hurd, 2014-02-23 In context of [[linux_as_the_kernel]], *IRC, freenode, #hurd, 2014-02-23*. mach seems like this really simple thing when you first explain what a microkernel is and because of that, i think it's better to start the right solution directly it looks simple, it's clearly not but i did a bit of looking into it... it's a bit non-trivial after all :) mach ipc is over complicated and error prone it leads to unefficient communication compared to other solutions such as what l4 does ya -- i hear that this is a big part of the performance hit that's why i've started x15 i was also doing some reading about how it's based on mapping memory segments between processes first, it was a mach clone, but since i've come to know mach better, it's now a "spiritual" mach successor .. :) these are two issues that we've been dealing with at another level... in the design of kdbus ah kdbus :) this is something that started with my masters thesis a long time ago... ah you too first thing we did is make the serialisation format so that all messages are valid and therefore never need to be checked (old dbus format requires checks at every step on the way) looks interesting then of course we cut the daemon out but some other interesting things: security is super-simple... it's based enirely on endpoints either you're allowed to send messages between two processes or you're not there is no checking for message types, for example yes and the other thing: memory mapping is usually bad that's what i mean when i say mach ipc is over complicated it depends 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 yes, we know that too that's why zero copy isn't the normal way of passing small amounts of data over mach either nice i got the impression in some of my reading (wikipedia, honestly) that memory mapping was being done all the time well no it's not memory mapping is unfortunately a small fraction of the performance overhead that's good :) that being said memory mapping can be very useful 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 weird bugs occur beyond 512M iirc you do want memory mapping for that ya... for things of this size.... you don't want to copy that through a socket :) monolithic kernels have it naturally, since the kernel is mapped everywhere for microkernels, it's a little more complicated and the problem gets worse on smp again, that's why i preferred starting a new kernel instead of reusing linux