Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 54

Thread: D-Bus Implementation Aiming For The Linux Kernel

  1. #31
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote Originally Posted by Ericg 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.
    Why dbus won't be rejected?
    Couldn't dbus library do the adjustments?
    Building dbus library on top of AF_BUS could be done transparently too.

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

    Default

    Quote Originally Posted by LightBit View Post
    Why dbus won't be rejected?
    Couldn't dbus library do the adjustments?
    Building dbus library on top of AF_BUS could be done transparently too.
    1) AF_BUS was rejected by the network stack maintainers because it couldnt be done without adding a new address space / COULD be done by extended the existing IPC stack. Presumably dbus in-kernel has enough features/advantages to off set this, plus Greg has enough pull with the developers to convince them this should go in

    2) Depends on libdbus' and AF_BUS' architecture

    3) You would first have to get AF_BUS INTO the mainline kernel which, as I mentioned in point 1 the network stack maintainer refuses to allow.

  3. #33
    Join Date
    Jun 2009
    Posts
    2,937

    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?
    What a strawman.

    I don't think I'm smarter than Microsoft engineers either, yet I don't want to use their solutions. I am not smarter than (and I certainly don't know better than) the engineers who created the Smart car, but I still don't want to use one.

    These are complex issues and disagreements are completely normal, needed, and positive, as long as they are civil and based on arguments. Open source is not some funky totalitarian dictatorship.

  4. #34
    Join Date
    Jan 2010
    Posts
    368

    Default

    Quote Originally Posted by Pawlerson View Post
    It sounds funny in BSD guy mouths. This approach will make Linux closer to BSD when comes to having core not spread in the wilds
    I'd say it's not comparable. A definite plus of the BSDs is that kernel and basic userland are developed in unison. This would definitely help Linux as well. It does not make much sense to separately maintain parts of the userland that interact closely with the kernel.

  5. #35
    Join Date
    Jan 2009
    Location
    Portugal
    Posts
    16

    Default

    Quote Originally Posted by Delgarde View Post
    According to Greg's comments on G+, it's his expectation that Binder could be re-implemented on top of this.
    Thanks for the response! I just read the additional comments on Greg's G+ post. If this kills the Binder on the kernel and makes D-Bus faster, what's not to like about it?

  6. #36
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

  7. #37
    Join Date
    Jan 2009
    Location
    Portugal
    Posts
    16

    Default

    Quote Originally Posted by LightBit View Post
    I love the README...

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

    Default

    Quote Originally Posted by HyperDrive View Post
    I love the README...
    Its a good attitude to have right now considering the project just started haha

  9. #39
    Join Date
    Oct 2012
    Posts
    299

    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.
    it is. that's exaclty the reason why the initiator of this wants it to move to kernel space.

    he has actually running an own kernel version running in the automotive industry exactly because of this. dbus as daemon might not be too slow for desktop systems but it is when it comes to embeded or low power devices.

    and it might also affect scientific calculations in some special cases.

    p.s. would helpo a lot if people would read more than the headline. a slightly deeper look at the background could answer a lot of questions and solve a lot of misassumptions.

  10. #40
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote Originally Posted by a user View Post
    it is. that's exaclty the reason why the initiator of this wants it to move to kernel space.

    he has actually running an own kernel version running in the automotive industry exactly because of this. dbus as daemon might not be too slow for desktop systems but it is when it comes to embeded or low power devices.

    and it might also affect scientific calculations in some special cases.

    p.s. would helpo a lot if people would read more than the headline. a slightly deeper look at the background could answer a lot of questions and solve a lot of misassumptions.
    Well I don't know what automotive industry is using dbus for, but maybe they should use MenuetOS instead or use better devices.
    My first reaction was a bit too harsh. I think this could be good, if done correctly.
    I had read more than the headline. I even found source code.

Posting Permissions

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