Originally posted by LightBit
View Post
Announcement
Collapse
No announcement yet.
D-Bus Implementation Aiming For The Linux Kernel
Collapse
X
-
-
Originally posted by LightBit View Post"Theoretically", ok lets say a lot faster, but I don't think dbus is too slow now.All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by LightBit View Post"Theoretically", ok lets say a lot faster, but I don't think dbus is too slow now.
Comment
-
Originally posted by Ericg View PostNo 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.
Comment
-
Originally posted by liam View PostI'm sure I'm missing something but since dbus, I believe, supports fd passing, where is the memcpy occuring?All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by HyperDrive View PostCould this replace Binder (on Android)...?
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.
Comment
Comment