diff options
Diffstat (limited to 'open_issues/dbus_in_linux_kernel.mdwn')
-rw-r--r-- | open_issues/dbus_in_linux_kernel.mdwn | 164 |
1 files changed, 0 insertions, 164 deletions
diff --git a/open_issues/dbus_in_linux_kernel.mdwn b/open_issues/dbus_in_linux_kernel.mdwn deleted file mode 100644 index 6f83db03..00000000 --- a/open_issues/dbus_in_linux_kernel.mdwn +++ /dev/null @@ -1,164 +0,0 @@ -[[!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 |