Kdbus Details

Jan 15th, 2014

Now that linux.conf.au is over, there has been a bunch of informationrunning around about the status ofkdbus and the integration ofit with systemd. So, here’s a short summary of what’s going onat the moment.

Lennart Poettering gave atalk aboutkdbus at linux.conf.au. The talk can be viewed here,and the slides are here. Go read the slides and watch thetalk, odds are, most of your questions will be answered there already.

For those who don’t want to take the time watching the talk,lwn.net wrote up a great summary of the talk, and that article ishere. For those of you without a lwn.netsubscription, what are you waiting for? You’ll have to wait two weeksbefore it comes out from behind the paid section of the website beforereading it, sorry.

There will be a systemd hack-fest a few days beforeFOSDEM, where we should hopefully pound out the remainingrough edges on the codebase and get it ready to be merged. Lennart willalso be giving his kdbus talk again at FOSDEM ifanyone wants to see it in person.

The kdbus code can be found in two places, both on google code,and on github, depending on where you like to browse things. In a fewweeks we’ll probably be creating some patches and submitting it forinclusion in the main kernel, but more testing with the latestsystemd code needs to be done first.

If you want more information about the kdbus interface, and howit works, please see thekdbus.txt file fordetails.

Binder vs. kdbus

A lot of people have asked about replacing Android’s bindercode with kdbus. I originally thought this could be done, butas time has gone by, I’ve come to the conclusion that this will nothappen with the first version of kdbus, and possibly can never happen.

First off, go read that link describing binder that I pointedto above, especially all of the links to different resources from thatpage. That should give you more than you ever wanted to know aboutbinder.

Short answer

Binder is bound to the CPU, D-Bus (and hence kdbus), is bound toRAM.

Long answer

Binder

Binder is an interface that Android uses to provide synchronous calling(CPU) from one task to a thread of another task. There is no queueinginvolved in these calls, other than the caller process is suspendeduntil the answering process returns. RAM is not interesting besides thefact that it is used to share the data between the different callers.The fact that the caller process gives up its CPU slice to the answeringprocess is key for how Android works with the binder library.

This is just like a syscall, and it behaves a lot like a mutex. Thecommunicating processes are directly connected to each other. There isan upper limit of how many different processes can be using binder atonce, and I think it’s around 16 for most systems.

D-Bus

D-Bus is asynchronous, it queues (RAM) messages, keeps the messages inorder, and the receiver dequeues the messages. The CPU does not matterat all other than it is used to do the asynchronous work of passing theRAM around between the different processes.

This is a lot like network communication protocols. It is a very“disconnected” communication method between processes. The upper limitof message sizes and numbers is usually around 8Mb per connection and anormal message is around 200-800 bytes.

Binder

The model of Binder was created for a microkernel-like device (sidenote, go readthis wonderful article about the history ofDanger written by one of the engineers at that company for a glimpseinto where the Android internals came from, binder included.) The modelof binder is very limited, inflexible in its use-cases, but verypowerful and extremely low-overhead and fast. Binder ensures that thesame CPU timeslice will go from the calling process into the calledprocess’s thread, and then come back into the caller when finished.There is almost no scheduling involved, and is much like a syscall intothe kernel that does work for the calling process. This interface isvery well suited for cheap devices with almost no RAM and very low CPUresources.

So, for systems like Android, binder makes total sense, especially giventhe history of it and where it was designed to be used.

D-Bus

D-Bus is a create-store-forward, compose reply and thencreate-store-forward messaging model which is more complex than binder,but because of that, it is extremely flexible, versatile, networktransparent, much easier to manage, and very easy to let fully untrustedpeers take part of the communication model (hint, never let this happenwith binder, or bad things will happen…) D-Bus can scale up to hugeamounts of data, and with the implementation ofkdbus it ispossible to pass gigabytes of buffers to every connection on the bus ifyou really wanted to. CPU-wise, it is not as efficient as binder, butis a much better general-purpose solution for general-purpose machinesand workloads.

CPU vs. RAM

Yes, it’s an over simplification of a different set of complex IPCmethods, but these 3 words should help you explain the differencesbetween binder and D-Bus and whykdbus isn’t going to be ableto easily replace binder anytime soon.

Never say never

Ok, before you start to object to the above statements, yes, we couldadd functionality tokdbus to have some blocking ioctl callsthat implement something like:write question -> block for reply and read reply one answerfor the request side, and then on the server side do:write answer -> block in readThat would getkdbus a tiny bit closer to the binder model, byqueueing stuff in RAM instead of relying on a thread pool.

That might work, but would require a lot of work on the binder libraryside in Android, and as a very limited number of people have writeaccess to that code (they all can be counted on one hand), and it’s anon-trivial amount of work for a core function of Android that isworking very well today, I don’t know if it will ever happen.

But anything is possible, it’s just software you know…

Thanks

Many thanks to Kay Sievers who came up with the CPU vs. RAM descriptionof binder and D-Bus and whose email I pretty much just copied into thispost. Also thanks to Kay and Lennart for taking the time and energy toput up with my silly statements about howkdbus could replace binder,and totally proving me wrong, sorry for having you spend so much time onthis, but I now know you are right.

Also thanks to Daniel Mack and Kay for doing so much work on the kdbuskernel code, that I don’t think any of my original implementation iseven present anymore, which is probably a good thing. Also thanks toTejun Heo for help with thememfd implementation and cgroupshelp in kdbus.

Posted by Greg Kroah-Hartman Jan 15th, 2014kdbus,linux

http://kroah.com/log/blog/2014/01/15/kdbus-details/