Systemd 221 Fixes Bugs, Wants Distributions To Start Shipping KDBUS

[liam]

I think there is a decent article on lwn regarding kdbus

Better one, for these purposes:

https://lwn.net/Articles/649111/

In short, what andy and eric have done is unprecedented, and it isn't uncommon for USERSPACE to make use of experimental kernel features (keep in mind, kdbus is basically a fricking driver, folks).
That's all this is.

[duby229]

I understand you don't want to merge my friend's KDBUS patches... It would be a shame if someone ... decided to add unremovable support for them in basic userland over which you have no control. Just a friendly reminder.

That makes no sense. Implementing kdbus in kernel space is what makes it unremoveable. Once kdbus is merged into the kernel it'll be there forever. If on the other hand someday dbus gets displaced by something else, distros at that time can decide to not use dbus, but kdbus will never go away.

[Mo6eB]

I understand you don't want to merge my friend's KDBUS patches... It would be a shame if someone ... decided to add unremovable support for them in basic userland over which you have no control. Just a friendly reminder.

[energyman]

Finally LP&co show that they are nothing but power mad little twerps.

It is all about power, not technical merit. All their lies are finally exposed as what they are.

KDBUS was not merged because it is broken by design. A bad solution for a none-existant problem.

But instead of listening, adressing the criticism and maybe sitting down and designing a better solution they show their true face and try to force KDBUS down the throats of all those people who know what broken mess the systemd crowd is pushing forward.

There is only one answer: boycott systemd and its toxic developers. They are actively destroying linux.

[Emmanuel Deloget]

Your last comment about a D-Bus "shim" is fascinating, since this is exactly what kdbus is;

Not exactly - kdbus is quite a large implementation of important D-BUS parts in the kernel. I think duby229 though to a new IPC mechanism on top of which one could develop a smaller kdbus API. That would make (IMHO) a lot of sense - but unfortunately, it's not what have been done.

[interested]

I really appreciate the civil tone. It would be great if it works out smoothly as you predicting. But the thing is, from my perspective we are already in the future, and it's not a good one. There is 13000 loc going into the kernel that 2 people sorta understand and one 1 person claims to understand but doesn't. Doesn't that sound like a bad idea to anyone else? I already don't use dbus and it's not easy to do. At some point somebody is going to -have to- develop a new IPC with a dbus compatibility shim.

kdbus is smaller than eg. a standard serial port driver. It isn't a big merge by Linux kernel standards.

There are many developers who understand and contribute to the kdbus codebase, probably more than usual for a new Linux feature.

The kdbus code isn't complex as eg. the Linux memory code. What gives some kernel developers problems are that they have little or no exposure to userland IPC. Just the fact that dbus/kdbus concerns itself with "policy" is enough to give many developers a glaze over their eyes. In short, if you don't understand D-Bus IPC, then kdbus code will be difficult to review. It will probably help with real world samples of userspace kdbus code to make them better grasp this new problem domaine.

Your last comment about a D-Bus "shim" is fascinating, since this is exactly what kdbus is; it replaces the D-Bus daemon with a backwards compatible kernel module and library that upgrades all existing D-Bus clients to using a new kernel IPC (kdbus).

And don't forget that while kdbus functions as a transport layer for the D-Bus protocol, it isn't tied to it. It is quite possible to invent a brand new non-D-Bus IPC and place it on top of kdbus. So the non-systemd, non-D-Bus distros can just make their own IPC and use kdbus to gain instant kernel features. Kdbus really is an advantage for everyone using the Linux kernel, whether you use systemd or not.

[interested]

I understand that, but he has distanced himself. Just read the logs. Honestly I think it's been pretty civil, but it's clear that kdbus is not wanted in the kernel by the majority.

The Linux kernel development have never worked that way; it is never a question about apparent consensus on LKML whether Linus Torvalds decide to merge a feature/patch or not. Linus relies on specific people he trust, on specific issues.

It doesn't matter if a horde of un-qualified people on LKML either wants a certain feature or not. What really matters is if one of Linus' lieutenants either NACKs or ACKs a feature/patch.

So far everything is just business as usual on LKML regarding kdbus, so it is likely that kdbus will be merged after a some further scrutiny. At the present the kdbus developers have addressed most if not all issues raised by serious LKML developers. So the next round (Kernel 4.2) will be interesting

[duby229]

your opinion is very important for us
not really
feel free to throw your computer out of a window

that 'vocal minority' reference was about braindead systemd-haters like you

Yeah, thanks for quoting out of context...... It really does make you -look- smart.

[pal666]

I -don't- wan't it

your opinion is very important for us
not really
feel free to throw your computer out of a window

That's not a minority. That's everyone.

that 'vocal minority' reference was about braindead systemd-haters like you

[duby229]

Yes, non-systemd distros that won't use kdbus will always have the option of removing any kdbus support from the kernel since kdbus is just a kernel module.

That some programs will start to use kdbus features is only natural. Those niche distros that won't use either D-Bus or kdbus will have to make sure that relevant userland projects supports that too, by either asking very nicely or provide the support themself.

Any choice has consequences, and if a distro chooses not to support the most widely used Linux/Unix IPC system and not even have an alternative to it, they must expect more work on their side or fewer choices in userland programs.

In practical terms, I don't think this will matter much for the non-systemd distros: A major point with kdbus is exactly that it is 100% backwards compatible with D-Bus, so few services outside those low-level ones like udev etc, have much incentive to use kdbus specific features. Daemon developers won't have to change a line of code in order to enjoy the benefits of a kernel IPC when the distro is using kdbus.

So the non-systemd distros can just continue to use the D-Bus daemon like they always had regarding most user land services.

I really appreciate the civil tone. It would be great if it works out smoothly as you predicting. But the thing is, from my perspective we are already in the future, and it's not a good one. There is 13000 loc going into the kernel that 2 people sorta understand and one 1 person claims to understand but doesn't. Doesn't that sound like a bad idea to anyone else? I already don't use dbus and it's not easy to do. At some point somebody is going to -have to- develop a new IPC with a dbus compatibility shim.