Re: [GIT PULL] kdbus for 4.1-rc1

Havoc Pennington
2015-04-15T18:41:18Z

On Wed, Apr 15, 2015 at 2:16 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> But can't a dbus library handle this for the apps? Like implementing TCP on
> top of UDP. I really doubt the entire dbus protocol needs to be pushed into
> the kernel.

You could probably do something like assign sequence numbers,
temporarily relax ordering, and then reconstruct the order where
needed, but somebody still has to assign the sequence numbers in
order, and the bus has to process requests in order (it can't flip a
subscribe and an unsubscribe, for example). So I don't know whether
you could get anywhere with it or not.

The current model (userspace dbus daemon, don't know about kdbus) is like this:

- you have a pool of ordered incoming queues from each client, where
each incoming queue conceptually ends with EOF of course

- the main bus loop does:
- pick the head message or EOF from any nonempty incoming queue for dispatch
- route it according to destination address or subscribers
- if the destination includes the bus itself (e.g. someone wanting
to subscribe or own a name or whatever) then process the request...
note that this will potentially affect how the next message gets
routed
- for each destination client, write the message to the ordered
outgoing queue for that client
- if the incoming queue has EOF then send out notifications about
that to interested clients, clean up bus names, etc.

Conceptually, filling and draining the queues could easily be in
separate threads, though the userspace daemon doesn't do that.

> I'm going to try to spend some time reading about dbus and playing with the
> code (thanks for the links BTW!). Then I can see if I can come up with
> something too. Or at least be able to ask the right questions.
>

Greg may be right to point people to Lennart's C binding which has a
lot less "baggage" than the GLib stuff, which assumes knowledge of the
"glib way"

Havoc