BUS1, The Successor To KDBUS, Formally Unveiled -- Aiming For Mainline Linux Kernel

[phoronix]

Phoronix: BUS1, The Successor To KDBUS, Formally Unveiled -- Aiming For Mainline Linux Kernel

BUS1 has been in development as an in-kernel IPC mechanism building off the failed KDBUS project. An "RFC" will soon be sent out to Linux kernel developers about BUS1 and the subject will be discussed at next month's Kernel Summit...

http://www.phoronix.com/scan.php?page=news_item&px=BUS1-Systemd-2016

[edoantonioco]

Better than kdbus? that sound interesting, and somehow Greg kh doesn't seems to be involved on this one, at least not on github. Is there any ETA?

[Naib]

butbutbut kdbus was perfect... that was the salespitch and it should have just been merged

[xeekei]

butbutbut kdbus was perfect... that was the salespitch and it should have just been merged

I don't remember it being sold as 'perfect'. It was more like 'drop in replacement, so applications won't need to adjust'.

[pal666]

butbutbut kdbus was perfect... that was the salespitch and it should have just been merged

idiots always remember their fantasies instead of reality. kdbus replicated libdbus behavior, it was perfect replacement. bus1 changes behavior, it will not be perfect replacement for libdbus

[Delgarde]

idiots always remember their fantasies instead of reality. kdbus replicated libdbus behavior, it was perfect replacement. bus1 changes behavior, it will not be perfect replacement for libdbus

That's about it, yeah. KDBUS was designed purely to allow the DBUS user-space APIs to be implemented on top of a kernel-space service... keeping backward compatibility was integral to the design. What I'm reading about BUS1, it *tries* for compatibility, but not at the expense of getting the design right... for user-space, it might not be quite as invisible a change as KDBUS was.

[staalmannen]

So will it be possible to implement binder on top of bus1 so that another big diff between mainline and Android can be removed?

[yoshi314]

idiots always remember their fantasies instead of reality. kdbus replicated libdbus behavior, it was perfect replacement. bus1 changes behavior, it will not be perfect replacement for libdbus

the problem was that it did not solve the problem it was supposed to solve (performance), and was completely insecure. it was far from perfect replacement. read that lkml thread again.

i think that coupling bus1 with some userspace compatibility wrapper that would act as a drop in replacement for dbus would also serve as a perfect replacement. assuming that bus1 is well designed and passes the review.

[Brane215]

Great. Looks at least conceptually very solid and well thought of wrt to performance issues and botllenecks.
When can we expect it in kernel and, perhaps more importantly, when can we expect to see it integrated into systemd ?

Allthough he says dbus doesn't need centrall arrbitrator app, exaclt for this lack of global context I suspect there will be "phonebook" app that will have an index who offers where and what, at least for those agenty that wnat to share in some non-local contexts.

This also means that there will be some sort of standardisation and adaptation period needed for everyone to catch up.

He mentions Wayland protocol, which I suppose would be great idea- one less low-level implementation to worry about and one more potential for performance boosting shortcut in the future.

[89c51]

He mentions Wayland protocol, which I suppose would be great idea- one less low-level implementation to worry about and one more potential for performance boosting shortcut in the future.

Could someone explain how wayland is involved with bus1? Does he mean rewrite of wayland to look more like bys1?