The Heated KDBUS Debate For The Linux Kernel Has Fizzled Out

[duby229]

In theory, perhaps. But it suffers from one big flaw - namely, that almost nobody actually uses it, whereas D-Bus has been the IPC mechanism of choice on Linux for the past decade. Technical superiority (real or imagined) has only passing relevance to which technology actually wins.

You are right, but it's kinda sad that's how it is. dbus is more than just an ipc, and not a good one at that. It's a shame that we have to be stuck with it in the future only because we are already stuck with it.

The real truth is, sometimes you have to let bygones be bygones. But, most people don't care what the real truth is.

[hubick]

Someone with the right knowledge should step up with a design for a general-purpose kernel IPC mechanism, like DBUS but taking all the feedback into account.

It's not every day the kernel needs a major new API that would have such broad usage, potential ports to other OS's like BSD, etc - that's something you could be really proud of, that goes far beyond patches to some driver or whatever. I'm sure the kernel dev's would help refine any proposal. If your work does get accepted, it would be so good on the resume that it would probably guarantee you jobs for life?

[gens]

dbus is for passing msgs between desktop applications (OO primarily), and for that it works now
transferring bulk data or something in real time requires a specialized IPC protocol, always has, always will

current bottleneck of dbus is its server, not context switching

[valeriodean]

Plumber, the IPC system from Plan 9 from Bell Labs is superior to D-Bus.
KDBUS is implemented as a socket type, reached by AF_DBUS.
Plumber is much simplier and you just read/write to a virtual file on the file system.

Hence Plumber is more Unix, in the way that it follows the Unix philosophy "everything is a file".
Also, since remote file systems may be mounted (done using 9P on Plan 9) it is also network transparent.

https://lists.debian.org/debian-user/2014/12/msg00802.html

Your info are outdated. Kdbus is implemented as a filesystem probably from the V2 or V3, for sure in the GIT PULL version.

[phrx_reader]

dbus is for passing msgs between desktop applications (OO primarily), and for that it works now
transferring bulk data or something in real time requires a specialized IPC protocol, always has, always will

current bottleneck of dbus is its server, not context switching

Hello, I think phoronix is missing two important postings in first week of May to lkml:

http://lkml.iu.edu/hypermail/linux/kernel/1505.0/00678.html

http://lkml.iu.edu/hypermail/linux/kernel/1505.0/01551.html

There Havoc Pennington, one of the main developers of dbus
http://en.wikipedia.org/wiki/Havoc_Pennington admits that dbus is a hack
(which kdbus is based on) compared to real capability-based IPCs such as
COM and Binder. Quoting Havoc:
"I guess you're really asking how all this relates to capabilities and
I don't know - dbus only looks at processes, not objects, for security
purposes, as far as I know. Objects are just a convention, the dbus
daemon doesn't actually care how a process interprets the object path
(or interface or method name, for that matter)."

[mark45]

The LKML is looking more and more like the US Congress, when a change is clearly needed yet the congressmen are the only ones not getting it and arguing for years.

[gens]

The LKML is looking more and more like the US Congress, when a change is clearly needed yet the congressmen are the only ones not getting it and arguing for years.

afaik the US Congress makes decisions only based on money
too bad you cant lobby Linus

[k1l_]

afaik the US Congress makes decisions only based on money
too bad you cant lobby Linus

which is Redhats real issue. the "linux community" was an easy one to get onto their side, not even needed much money; just some well played shitstorms and forced dramas against easy targets and opponents like canonical.

[gens]

which is Redhats real issue. the "linux community" was an easy one to get onto their side, not even needed much money; just some well played shitstorms and forced dramas against easy targets and opponents like canonical.

to be honest, i think the push is more from passion of a few systemd devs
then again all of what they want can be done by fixing up the dbus daemon

but ye, just put "red-hat engineer" on something and the crowd goes wild

[justmy2cents]

Hello, I think phoronix is missing two important postings in first week of May to lkml:
http://lkml.iu.edu/hypermail/linux/k...5.0/00678.html
http://lkml.iu.edu/hypermail/linux/k...5.0/01551.html
There Havoc Pennington, one of the main developers of dbus
http://en.wikipedia.org/wiki/Havoc_Pennington admits that dbus is a hack
(which kdbus is based on) compared to real capability-based IPCs such as
COM and Binder. Quoting Havoc:
"I guess you're really asking how all this relates to capabilities and
I don't know - dbus only looks at processes, not objects, for security
purposes, as far as I know. Objects are just a convention, the dbus
daemon doesn't actually care how a process interprets the object path
(or interface or method name, for that matter)."

i'm guessing you didn't understand or didn't read the rest. this is complete opposite from being hack and makes total sense.

read this

Anyhow... so the big picture is this different design emphasis. dbus
is solving multicast/singleton/multi-process first, and then making it
look sort of OO-ish in the language binding library. COM is solving
"C++ has an impoverished runtime with a fragile ABI" first, and then
bolting on "hey we could make these fancied-up objects be out of
process sometimes."

and

dbus is exposing more implementation detail than COM - it explicitly
is always about processes (ok, technically bus connections, but the
point is: not objects). You can track the processes themselves (via
the bus names). dbus encourages writing async code, again exposing
that we're dealing with remote objects. dbus encourages you to just
use your language's native runtime for in-proc objects.

Havoc is not saying that dbus is a hack, he says design and goal were different from COM and Binder (which he was asked about in comparison to dbus) for various reasons. mainly flexibility. and if you ever coded with COM, Binder and dbus you'd see why dbus is so much better to use in code