Greetings. On Sat, 09 Feb 2013 08:25:21 +0100 Alex Pilon <a...@alexpilon.ca> wrote: > Apologies in advance to Plan9 and plumb users if this topic has been > done to death. > > "Greg Kroa-Hartman writes about plans to get D-Bus functionality into > the kernel" and more. > > http://lwn.net/Articles/537017/rss > > Anybody else almost have an aneurysm due to the wording? Seriously, the > idea of multicast point-to-point messaging in-kernel doesn't sound bad > to me but this and a libdbus-like interface just stinks, or anything in > bed with GObject crap for that matter. What are your thoughts on the > general concept? If it's more than just very simple multicasting, of > course I woudn't advocate that in kernel space.
If it’s done right this is not wrong. It would be really sad if the mis‐ designed wire format of dbus is enforced in such a kernel feature. Es‐ pecially the authentication of dbus is switching between parsing modes and styles of protocols. Whoever did this protocol does not like other people reimplementing their idea. A nice way to do such a bus in kernel would be a local way of TCP/IP with pre‐defined addresses and connections you open with some io vectors to define the bounds of the packets and a simple way of applications to register to multicast events. Of course all of this with credentials in the kernel enforced so no authentication is needed and you simply send data over the filedescriptor, with no library or wire‐format enforced. The person who did libdbus should get thrown into th same hole as the one who designed the dbus protocol. I would support dbus, if it would be a sane IPC protocol and not en‐ forced where there are system IPC ways already. The library of dbus sucks, the naming scheme of objects, the enforcing of some sect (FDO.org) in the standard, the library function names are too long, the pseudo‐abstraction of objects is crap, the XML definition of these ob‐ jects makes me puke and all of this complexity makes it impossible for the current maintainers of dbus and all of its crap above to have an overview and strip down the bottlenecks. That’s what you get for design‐ ing something from the ground up in the wrong way. Sincerely, Christoph Lohmann
