Unfortunately the response from David Miller (the net/ maintainer) was that he was going to ignore the series without even looking at it (he did), because he felt multicast was sufficent (it wasn't). And here we are.

It seems to follow that kdbus (and perhaps Android's "binder" as well) would either integrate elbow-deep with the scheduler, be using a general interface shared between the fresh-faced new IPC mechanisms to that effect, or be nothing special and therefore unworthy. My two Internet cents rest on the lattermost hypothesis' eyelids.

The unhappiness about speed is quite interesting. Was kdbus developed without a way to measure performance in comparison to the user-space solution, one of its stated & well-publicized design requirements? Surely such critique is the easiest to overcome: just slap down "my first rdtsc" and iterate until it's any good.

Moreover there are several Free Software super-scalable message-queuing frameworks kicking around in the enterprise middleware space right now; for example 0mq and its descendants-in-spirit. These seem to do just fine even without a kernel-side bypass lane. Why is that? Why do parallel computing interfaces like MPI manage full utilization of both local and clustered resources without going into the kernel, but dbus must pierce that veil?

Far be it from me not to suspect that kdbus is a way to cement the systemd takeover of GNU/Linux userspace. These pro-kdbus arguments of inevitability, undifferentiated from those for old GNOME's Bonobo/ORBit, and similes to "buggy hardware" which software by definition isn't, seem vacuous and technically inept like those used to back systemd in the first place; and the absence of concrete advantage beyond "it'll be over as soon as you stop resisting" just makes it seem all the more consciously wack.

I much prefer Linus's brand of abusiveness, which is at least unapologetic and cites its sources.

> If you put aside the way too many tongue lashings then technical criticism that has taken place in response to Greg ( which says more about the kernel community abusiveness than about kdbus design choices )

And then:

> Those responding expert individuals that trust nobody but themselves [...] can step up of their iron thrones [...] rainbow farting pony's [...] everyone will be bathed in it's [...] fairy dust [...]

Conclusio:

> So seriously shut up and commit that code already this is getting ridiculous...

Oh, goody. You have convinced me now.

Seriously: if we don't learn (and I mean ALL sides) to dial down our egos a bit and just accept that the others aren't idiots either, this is going to be less and less fun.

AFAIU the reason for adding the meta-data was to have access to it in a race-free manner, that the user-space is going to need that data anyway but if it has to go look for it itself the need information might already have changed/disappeared.

What I don't understand is why these meta-data structures couldn't change saying that otherwise user-space would break. If user-space is already using that information today how does it not break when they change those structures in the kernel?

kdbus does not expose anything that is not already exposed to userspace, it is simply making sure the exposed data can be retrieved in a race-free manner.

The meta-data is used for authentication, logging and introspection purposes, not just "logging". Of the various fields we provide, some are useful for authentication, and others for introspection, and others for logging, some for all three cases, others for two cases. It really depends.

And the "logging data stream" should not be separated out, since we provide it so that the recipient of a method call can properly log about the method call it is executing, about what it is doing for it, and on which behalf it is doing it, all in a race-free fashion, in one log record. If you however split things into multiple streams, you will have difficulty matching up the events from the streams, and things will be necessarily raceful.

Lennart

So if you do get 'kgenericipc' in that will not really relieve the need/desire for kdbus-like functionality. Then you will just end up with 2 sets of API/ABIs to maintain instead of just one.

This is why it's so critical to get it right. It's going to be used almost immediately by a huge number of different things. If it was to get in now you'll see distributions shipping significant amount of software that requires it by the end of the year. If it's wrong now there is never going to be any chance to fix it.

On the upside I am willing to be that a lot of it's 'crapiness' is due to the fact that it's initial design has been fine tuned and fixed over the years and what often appears to be kludges is just a sign of a maturity.

A lot of people have said this over the past 12 years, and yet no viable replacement has emerged.

Havoc wrote an extremely eloquent mail explaining why the model was as it was: because applications a) did not want to use a more complex model requiring them to manage their own state, and b) were likely to get such a model wrong, resulting in security flaws among others.

Any replacement for D-Bus must therefore retain many of its same properties, and that no such replacement has emerged (with the criticisms largely being of its design goals), probably says quite a bit about its quality.

Easy. Remove it. Throw all of this broken second-system nightmare out the window, and all its workarounds, and all their workarounds too. Let's go *forward* to what actually worked before all this fd.o crap came along.

In the old days, distros allowed non-root users to do scary and evil things like shut down, mount USB sticks and generally use their own computer by way of setuid-root or setcap helper binaries, or background services talking over a socket — those didn't need you to pass through a digital TSA checkpoint before they'd talk to you. In this savage and primitive culture there was no PolicyKit, or ConsoleKit, or UKit, or KitKitFactoryFactory, or libxml, or a Javascript VM, or HALd, or udevd, or SELinux, or dbus. Did the world end for lack of those? Hardly, the OS was *more* usable and *more* secure than it is today!

To those who would cry "we need all this": you're lying and you know it.