BUS1 Didn't Land This Year, But It's Making Progress

[EduRam]

There is something new on the BUS1 or DBUS front:

https://github.com/bus1/dbus-broker/

[tomtomme]

Again that is completely wrong. At no point did Linus T. nor anybody else claim that kdbus was slow. What Linus T. pointed out that was that user space dbus daemon was slow because it was inefficiently optimized. And unoptimized user space code is no reason for moving code to kernel space (see the old TUX discussion on LKML for that).

Again, at no point did Linus claim kdbus was slow and consequently never NACKed kdbus for not being fast enough, in fact in the quoted post he explicitly says he expect to merge kdbus into the mainline Linux kernel tree if asked.

I read it again and you are right. I read that wrong.
Linux said dbus is slow because it was written badly, thus the argument kdbus is faster is like saying my ferrari (kdbus) is faster than your Trabbi (dbus). Anything is faster than the Trabbi. Thus the pro-kdbus argument is faster wath bogus to him.

[pal666]

It is IPC? Yes. Are there other IPCs already in the kernel? Yes. => just another ipc.

where does your "just" come from? it is ipc which has no analogs. one of a kind ipc in other words

It is basically a binder with multicast and message ordering (but who really needs them?)

lol. who really needs computers?

[Stellarwind]

it is not just another ipc. it is bus1. you could read its docs if you want to know difference

It is IPC? Yes. Are there other IPCs already in the kernel? Yes. => just another ipc.
It is basically a binder with multicast and message ordering (but who really needs them?)

[interested]

and a bug in the kernel code runs as uid 0

So what. Are you seriously arguing that Linux kernel features like drivers and the networking stack etc. should never be used because they may contain bugs? Your argumentation is simply bat shit crazy when it comes to the Linux kernel.

A kernel based IPC like bus1 will without doubt be a much more secure than any existing user space alternative.

[trek]

One of the reasons for having kernel IPC like bus1 is exactly the increased security since it gives LSMs (Linux Security Modules) a chance to eg. inspect and control bus messages from the kernel, instead of from the much more insecure user space.

and a bug in the kernel code runs as uid 0

[interested]

No, simply because I don't want to read the whole LKML thread once again.

If you don't want know the basic facts of kdbus because it requires you to put in a minimal effort of reading a few pages on LKML, then you should perhaps stop posting your invariable false ideas about kdbus.

If kdbus was going to be merged why did they abandon it, after being so determined to mainline it?

First, parts of kdbus has already been merged into the mainline (memfd in 3.17).
Secondly, bus1, despite being a different beast altogether, is also the successor to kdbus. So the goal of kdbus still exist though bus1 is now much more ambitious and generic solution.

So this is just totally standard LKML procedure; developers propose something, it gets criticized on LKML, the developers redevelop the patches in response etc. Sometimes this means that the finally accepted code is a totally new design that bears little resemblance with the original proposal.

In this case one of the first questions several kernel developers asked when kdbus was proposed, was why kdbus wasn't much more generic. Since the Linux kernel doesn't have any good generic IPC, many developers would really like such a generic solution instead of the much more scope limited shared bus design of kdbus. bus1 is exactly such answer to that criticism.
They also removed any direct or indirect links to dbus so that the inherently slow design of dbus doesn't turn this into a TUXv2 debate about user space vs kernel code. They still expect to run dbus on top of bus1, just like on kdbus though.

In short, the goal of kdbus still lives on in bus1, but in a new much more ambitious form in response criticism on LKML, and that is just how lots of kernel development is done.

[interested]

I remember one reason to not merge kdbus yet was, that it did not deliver performance wise. And performance was one of its primary goals over dbus. Its written in linus lkml post thats linked above, but only partly cited.
why the devs did not fix perf, i dont know. Maybe they are still trying.

Again that is completely wrong. At no point did Linus T. nor anybody else claim that kdbus was slow. What Linus T. pointed out that was that user space dbus daemon was slow because it was inefficiently optimized. And unoptimized user space code is no reason for moving code to kernel space (see the old TUX discussion on LKML for that).

Again, at no point did Linus claim kdbus was slow and consequently never NACKed kdbus for not being fast enough, in fact in the quoted post he explicitly says he expect to merge kdbus into the mainline Linux kernel tree if asked.

[tomtomme]

I remember one reason to not merge kdbus yet was, that it did not deliver performance wise. And performance was one of its primary goals over dbus. Its written in linus lkml post thats linked above, but only partly cited.
why the devs did not fix perf, i dont know. Maybe they are still trying.

[darkbasic]

which is probably why you haven't backed it up with a LKML quote.

No, simply because I don't want to read the whole LKML thread once again. If kdbus was going to be merged why did they abandon it, after being so determined to mainline it?