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

[phoronix]

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

What you will not find as part of the list of new Linux 4.10 kernel features is BUS1, the successor to the un-merged KDBUS initiative and a new approach for in-kernel IPC. While it didn't land in 2016 to the mainline kernel, it's making progress...

http://www.phoronix.com/scan.php?page=news_item&px=BUS1-Progressing-For-2017

[Daktyl198]

Can somebody explain the point of BUS1? Wasn't the reason for KDBUS to move DBUS to the kernel for speed/security reasons, and make it so that nobody has to re-write their programs? If BUS1 is different than DBUS, it completely defeats the entire point of the venture.

[darkbasic]

Yes, but Linus will never ever accept kdbus upstream because it is bad by design (and it has to if it wants to be retro compatible), so they had to write a completely new protocol.

[Daktyl198]

Yes, but Linus will never ever accept kdbus upstream because it is bad by design (and it has to if it wants to be retro compatible), so they had to write a completely new protocol.

My point then becomes: why would Linus accept THIS protocol upstream when there isn't a reason for it anymore? It's JustAnotherIPC at this point

[cl333r]

Can somebody explain the point of BUS1? Wasn't the reason for KDBUS to move DBUS to the kernel for speed/security reasons, and make it so that nobody has to re-write their programs? If BUS1 is different than DBUS, it completely defeats the entire point of the venture.

kdbus had a security flaw that couldn't be fixed. A new API had to be created, and while at it, the requirement to cater to dbus was dropped and now bus1 is a general purpose API.

[ssokolow]

My point then becomes: why would Linus accept THIS protocol upstream when there isn't a reason for it anymore? It's JustAnotherIPC at this point

Because it's aiming to be a half-way between full-fleshed APIs like D-Bus and primitives like "seal memory" that can eventually become "The one true in-kernel IPC" which future IPC systems are built upon. (eg. I believe I remember seeing in a talk that one hope is that Binder can be rebased upon it.)

[jacob]

Because it's aiming to be a half-way between full-fleshed APIs like D-Bus and primitives like "seal memory" that can eventually become "The one true in-kernel IPC" which future IPC systems are built upon. (eg. I believe I remember seeing in a talk that one hope is that Binder can be rebased upon it.)

This would make sense. AFAICT the philosophy of Linux (as opposed to some other kernels, notably NT and also FreeBSD) has always been to expose very low level APIs and let features that are actually usable be implemented in userland on top of them. The question is then, why do we need BUS1? Why can't D-Bus be rewritten to use memory seals instead?

[Azrael5]

what's the purpose of kdbus dbus bus1!?

[Brane215]

what's the purpose of kdbus dbus bus1!?

Isn't it obvious ?
bus2.

[Azrael5]

Isn't it obvious ?
bus2.

ok I understand so we'll wait for bus3

I feel this API concern with free cache memory operation. Right?