DBus in the kernel?

[Havoc Pennington]

I did have the same immediate reaction as Michael - given that
libdbus/dbus-daemon are way slow, before context switches ever come
into play, if speed were the issue I think you could get pretty far in
userspace. Current dbus implementation just isn't implemented with
speed as a driving force. (coding it, I considered avoiding/batching
round trips, keeping things async, a lot more important than
throughput.)

That said, if people want to mess with kernel dbus, that's cool. It
might be wise to write some more test suite for the semantics of the
bus routing and bus policy stuff - it's reasonably involved.
dbus/bus/dispatch.c etc. I'd kinda want test cases on every important
codepath and situation in there (and maybe add descriptions of the
behavior to the spec) if I were reimplementing the bus.
Could be tricky to set up the current tests and any new ones to
support running against both daemon and new daemon.

One design I used recently for a protocol-reading/writing library that
could be interesting for a future libdbus variant: have a reader
thread and writer thread using a blocking API to read/write messages.
A blocking API for reading and writing can be implemented a fair bit
more simply than the current code, I believe, and be faster and
smaller for apps willing to block. Then on top of the blocking API,
implement something like DBusConnection using the two threads to read
and write, and pulling read/written stuff into the main loop. (Which
makes the DBusConnection type API look async and unthreaded.) Results
in a good bit cleaner code than the way dbus-connection.c and
dbus-transport*.c work now perhaps.

Havoc