D-Bus Implementation Aiming For The Linux Kernel

[LightBit]

IPC clients are probaly still gonna talk dbusish. Having in-kernel IPC is just a matter exploiting the advantages.

AF_BUS itself is protocol agnostic and implements the configured policy between attachments which allows for a bus master to leave a bus and communication between clients to continue.

http://lwn.net/Articles/504722/

Perhaps the blog post this whole thread is about contains the answer: http://www.kroah.com/log/linux/af_bus.html

Not it doesn't.

[strcat]

Why not build dbus library on top of AF_BUS?

Perhaps the blog post this whole thread is about contains the answer: http://www.kroah.com/log/linux/af_bus.html

[funkSTAR]

Why not build dbus library on top of AF_BUS?

IPC clients are probaly still gonna talk dbusish. Having in-kernel IPC is just a matter exploiting the advantages.

Sure thing though; having the evil cabal doing stuff will start forks. Within a week we can expect a ebus fork. E for experimental. It will live in the realms of gentoo. Sure thing.

[LightBit]

No but its also the issue of finally getting Kernel-IPC "right." If we had gotten IPC right the first time we wouldn't have required AF_BUS or Dbus, since we DID come up with those 2 followups there's obviously something wrong with whatever the current implementation is. Going with dbus has the added bonus of speeding up any dbus-enabled program which is.... all of Gnome, KDE, XCFE, any program designed FOR those DE's...do you see a pattern forming? Pretty sure Greg has a phoronix account, I'd love for him to post the exact downsides of the current IPC mechanism.

Why not build dbus library on top of AF_BUS?

[Delgarde]

Could this replace Binder (on Android)...?

According to Greg's comments on G+, it's his expectation that Binder could be re-implemented on top of this.

People are getting hung up on the idea that they're moving the entire dbus daemon into the kernel, but that doesn't appear accurate. Rather, they're designing a new IPC mechanism in the kernel that dbus and Binder could be built on. There's no detail available yet, but I assume the kernel will provide a framework for delivery of generic messages, while the existing userspace code will remain responsible for the API and the structure of those messages.

[Ericg]

I'm sure I'm missing something but since dbus, I believe, supports fd passing, where is the memcpy occuring?

Ask Greg next time he pops on the forums or head to his G+ page, he's the one who brought it up.

[liam]

No but its also the issue of finally getting Kernel-IPC "right." If we had gotten IPC right the first time we wouldn't have required AF_BUS or Dbus, since we DID come up with those 2 followups there's obviously something wrong with whatever the current implementation is. Going with dbus has the added bonus of speeding up any dbus-enabled program which is.... all of Gnome, KDE, XCFE, any program designed FOR those DE's...do you see a pattern forming? Pretty sure Greg has a phoronix account, I'd love for him to post the exact downsides of the current IPC mechanism.

I'm sure I'm missing something but since dbus, I believe, supports fd passing, where is the memcpy occuring?

[pingufunkybeat]

Aw! I just wanted to post that! Stop ruining all our trolling fun!

They are doing it backwards. They should be merging the kernel and D-Bus into SystemD. Then rejecting Linus' patched :P

[libv]

We need to merge Gnome, systemd, ... into kernel and make Linux even more bloated.

Aw! I just wanted to post that! Stop ruining all our trolling fun!

[DeepDayze]

"Theoretically", ok lets say a lot faster, but I don't think dbus is too slow now.

I'm sure that d-bus will be optimized even better so that it can work in a kernel context..this will be interesting to see how this change to a kernel d-bus will impact the performance of the kernel