Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 54

Thread: D-Bus Implementation Aiming For The Linux Kernel

  1. #11
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,939

    Default

    Quote Originally Posted by LightBit View Post
    Why? dbus daemon works. This will only make dbus little faster.
    Theoretically twice as fast since it would cut the amount of mem-copy's in half and a copy is about the most expensive thing you can do in software...

  2. #12
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote Originally Posted by Ericg View Post
    Theoretically twice as fast since it would cut the amount of mem-copy's in half and a copy is about the most expensive thing you can do in software...
    "Theoretically", ok lets say a lot faster, but I don't think dbus is too slow now.

  3. #13
    Join Date
    Jul 2011
    Posts
    379

    Default

    I thought it was related to the sandboxing stuff phoronix wrote about some days ago?


    Besides that is systemd qualified to be "Minimal dependencies and footprint (does not require POSIX shell or D-Bus)" in the openrc article on Wikipedia now

  4. #14
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,939

    Default

    Quote Originally Posted by LightBit View Post
    "Theoretically", ok lets say a lot faster, but I don't think dbus is too slow now.
    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.

  5. #15
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    983

    Default

    Quote Originally Posted by LightBit View Post
    "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

  6. #16
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    342

    Default

    Quote Originally Posted by LightBit View Post
    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!

  7. #17
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    Quote Originally Posted by libv View Post
    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

  8. #18
    Join Date
    Jan 2009
    Posts
    1,496

    Default

    Quote Originally Posted by Ericg View Post
    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?

  9. #19
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,939

    Default

    Quote Originally Posted by liam View Post
    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.

  10. #20
    Join Date
    Apr 2010
    Posts
    819

    Default

    Quote Originally Posted by HyperDrive View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •