KDBUS Is Taking A Lot Of Heat, Might Be Delayed From Mainline Linux Kernel

[stalkerg]

kdbus not needed!
The problem is not in the dbus but the fact that someone is trying to send thousands of messages through the IPC. kdbus improve the situation but did not fix it. This crutch (for RedHat enterprise people).

IPC in kernel maybe... but not need clone dbus. Dbus good working in userspace for normal task.

[YoungManKlaus]

The problem is not in the dbus but the fact that someone is trying to send thousands of messages through the IPC

Performance is not the only reason for kdbus (correct meta-data being another one often mentioned). Also if I have a fast/reliable message bus other already-existing services would profit (real-time audio, ...) all of which you would know had you bothered to read and understand the whole thread.

Actually, just read the pull request, it contains a huge list of summaries why kdbus (as a concept) is a good idea.

[stalkerg]

Performance is not the only reason for kdbus (correct meta-data being another one often mentioned).

Bad security model as point to critics too.

Also if I have a fast/reliable message bus other already-existing services would profit (real-time audio, ...)

Ok, please push JACKd to kernel. For sound stream need more than have in dbus.

all of which you would know had you bothered to read and understand the whole thread.

I read the whole thread.

Actually, just read the pull request, it contains a huge list of summaries why kdbus (as a concept) is a good idea.

This is a crutch for the current practices and architecture.

[interested]

This is a crutch for the current practices and architecture.

<sarcasm>Yes, lets rewrite the entire Linux kernel each and every Linux daemon from scratch and change all current developer practices in order to have an ivory tower designed IPC. Lets break user space ABI too since legacy code is just a wrong concept.</sarcasm>

There is an actual need and good user cases for a dbus compatible kernel IPC. Any real alternative to the kdbus concept is likely to be a strictly systemd and Linux-only solution, and will require a lot of work in order to change user land applications.

[stalkerg]

Any real alternative to the kdbus concept is likely to be a strictly systemd and Linux-only solution

Why?

PS I am OpenRC user...

[interested]

[snip: about alternatives being systemd only]

Why?

PS I am OpenRC user...

There are several scenarios; the systemd developers make a kludge IPC build upon available IPC mechanism's already in the kernel, even "Binder" could be a part of it. They will abstract the low level stuff away in a nice API for developers through libs and proxies, but there will be no stable internal API/ABI that means it will be an uphill struggle for anyone to reverse engineer and keep up with changes, and lets face it; close to 100% of all commercial Linux distros are going with systemd, so there will practically be no paid developers working on that, so when user space starts to migrate away from dbus to the systemd IPC, everybody else will be screwed. The advantage with kdbus is a stable API that anyone can write for and use, and in fact, don't need to change a single line of code in order to take advantage off.

Even if some brand new non-dbus compatible kernel IPC materialize in a couple of years, it would still need some kind of front end (mediator) in order not to expose internal kernel knobs directly and various support libraries and developer tools. Only the systemd distros really have that kind of developer power, and again, the mediator will be in systemd, just like the cgroups mediator. Dropping dbus in favour of such a new IPC will place a huge developer burden on non-systemd distros and BSD variants, the BSD variants may make it, but non-systemd distros will just wither away. Dbus, with all its advantages and warts is a standard cross platform solution, while any Linux kernel IPC seeking to replace it, per definition will be Linux only.

[gens]

Performance is not the only reason for kdbus (correct meta-data being another one often mentioned). Also if I have a fast/reliable message bus other already-existing services would profit (real-time audio, ...) all of which you would know had you bothered to read and understand the whole thread.

hell no !
audio should go only over shm in a ringbuffer, as it goes for JACK and alsa
anyone who thinks that streaming audio in packages is a good idea does not know shit about what s/hes talking about

[tomegun]

If there is so much contention about adding a dbu1 compatible kdbus into the kernel right now then why can't it be fully implemented as a kernel module such that nothing, or very little, of the rest of the kernel has to be modified?

If the entire kdbus system could be isolated via the standard kernel module interface then "we" could have at it asap and those who want a newer/better dbus2 or kbus implementation can work on it with the benefit of hindsight from the current kdbus being available for real (not just in theory). And for those who don't need or want it then it's simply a rmmod away.

This is exactly how it is done. kdbus is just a kernel module.

[chithanh]

The issue is not that kdbus makes extensive changes to existing kernel functions (it doesn't), the issue is that it creates new userspace-facing API. API which then has to be supported indefinitely, and that not everybody agrees with.

[duby229]

The issue is not that kdbus makes extensive changes to existing kernel functions (it doesn't), the issue is that it creates new userspace-facing API. API which then has to be supported indefinitely, and that not everybody agrees with.

The problem with kdbus is that it's a port of dbus. And dbus was -designed- to be misused. The way dbus gets used today by most applications is shameful and wrong.