From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- open_issues/dbus_in_linux_kernel.mdwn | 90 ++++++++++++++++++++++++++++++++++- 1 file changed, 89 insertions(+), 1 deletion(-) (limited to 'open_issues/dbus_in_linux_kernel.mdwn') diff --git a/open_issues/dbus_in_linux_kernel.mdwn b/open_issues/dbus_in_linux_kernel.mdwn index caf47711..6f83db03 100644 --- a/open_issues/dbus_in_linux_kernel.mdwn +++ b/open_issues/dbus_in_linux_kernel.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] +[[!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 @@ -74,3 +75,90 @@ Might be interesting to watch how this develops. [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 -- cgit v1.2.3