Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 54

Thread: D-Bus Implementation Aiming For The Linux Kernel

  1. #21
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    390

    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.
    Why not build dbus library on top of AF_BUS?

  2. #22
    Join Date
    Dec 2011
    Location
    Basement
    Posts
    389

    Default

    Quote Originally Posted by LightBit View Post
    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.
    Last edited by funkSTAR; 02-09-2013 at 04:36 AM.

  3. #23
    Join Date
    Mar 2011
    Location
    Canada
    Posts
    97

    Default

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

  4. #24
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    390

    Default

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


    Quote Originally Posted by strcat View Post
    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.
    Last edited by LightBit; 02-09-2013 at 04:45 AM.

  5. #25
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,798

    Default

    I have to admire all those posters in this thread who think they're smarter, more capable and know better than Greg. You're all kernel devs, right?

  6. #26
    Join Date
    Dec 2011
    Location
    Basement
    Posts
    389

    Default

    Quote Originally Posted by RealNC View Post
    I have to admire all those posters in this thread who think they're smarter, more capable and know better than Greg. You're all kernel devs, right?
    Better than Greg? No better than Greg, Kay and Lennart combined. The moronix elite can fork their way to "less bloat and more UNIX" What a bunch of neckbearded forksters.
    Last edited by funkSTAR; 02-09-2013 at 05:35 AM.

  7. #27
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    390

    Default

    Quote Originally Posted by RealNC View Post
    I have to admire all those posters in this thread who think they're smarter, more capable and know better than Greg. You're all kernel devs, right?

    Why so many people think, if somebody is complaining about something, he think he is smarter, more capable and know better?

    I'm only concerned that he is focusing on performance too much.
    It's funny when you read "The Linux Kernel Console Is Being Killed Off" and than "D-Bus Implementation Aiming For The Linux Kernel".

    More info is needed about this:
    - How many new system calls will be requred? (AF_BUS reuses networking system calls)
    - How many lines of code in kernel?

  8. #28
    Join Date
    Oct 2012
    Posts
    148

    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.
    Couldn't agree more. I simply don't understand what was happening in the minds of Unix developers where they designed an IPC system which has no guarantees where the message will end up (not even round-robin, just random) and is basically one-way only.

    There's a need for a multicast IPC system and AF_BUS doesn't cut it for mainline so Greg (and few other people) work on something better.

  9. #29
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote Originally Posted by LightBit View Post
    Yes it does. AF_BUS has been consistently rejected by upstream. Using it would mean adjusting every dbus program, meanwhile moving from dbus-daemon to kernel-dbus could be done transparently.

  10. #30
    Join Date
    Jul 2011
    Posts
    368

    Default

    As I understand it it's not kernel dbus. It's a generic IPC in the kernel. In the user space they have a frontend so they get compatibility with the different formats like dbus or binder? I suppose the dbus frontend is Poetterings share of it (or it was a joke, I'm not completely sure..)

Posting Permissions

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