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

[jonaslundqvist]

That is simply untrue. Linus T. explicitly said on LKML that he would merge kdbus if asked. You can find Linus actually saying this on the LKML. So whoever told the above was simply making things up.

https://lkml.org/lkml/2015/6/23/657

So I am still expecting to merge it, mainly for a rather simple reason: I trust my submaintainers, and Greg in particular. So when a major submaintainer wants to merge something, that pulls a *lot* of weight with me. That said, [... rant about DBUS sucking ...] We don't merge kernel code just because user space was written by a retarded monkey on crack. [... rant about DBUS sucking ...]

[pal666]

Why can't D-Bus be rewritten to use memory seals instead?

why don't you read its docs for education?

[darkbasic]

That is simply untrue. Linus T. explicitly said on LKML that he would merge kdbus if asked. You can find Linus actually saying this on the LKML. So whoever told the above was simply making things up.

Maybe not Linus himself, but the subsystem maintainers for sure. There were design flaws due to the backward compatibility which prevented any possible merge for the kernel standards.

[interested]

Maybe not Linus himself, but the subsystem maintainers for sure.

Sure, Luto did at one point NACK kdbus, but that was just a NACK of the current patch set, not kdbus as an idea. It is extremely common for patches to be NACK'ed many times before they get an ACK. That is just standard fare for most patches on LKML, some patches goes into 5-10 revisions before getting an ACK.

The point is that Linus T. knows all that, which is why he said he was going to merge kdbus. And when Linus says that, he means it. Even if Luto still had maintained his NACK Linus would probably have merged kdbus anyway judging by his past actions.

There were design flaws due to the backward compatibility which prevented any possible merge for the kernel standards.

Please stop making stuff up; your statement is totally untrue which is probably why you haven't backed it up with a LKML quote.

kdbus was a kernel module with extremely little interaction with the rest of the kernel, there would have been no problems with "kernel standards" (whatever you mean by that).

You are also wholly confused when you talk about "backward compatibility". I assume you mean something with "dbus" compatibility. But really, kdbus was just a shared bus that could run many kinds of user IPC's, including dbus, but that was all in user space. There were never a trace of dbus in the kernel module (as said, it was just a shared bus).

In short, such problems never existed.

[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?

[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.

[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.

[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.

[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]

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.