Announcement

Collapse
No announcement yet.

D-Bus Implementation Aiming For The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    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.

    Comment


    • #32
      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.
      All opinions are my own not those of my employer if you know who they are.

      Comment


      • #33
        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.

        Comment


        • #34
          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.

          Comment


          • #35
            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?

            Comment


            • #36
              Kernel "dbus-like" code for the Linux kernel. Contribute to gregkh/kdbus development by creating an account on GitHub.

              Comment


              • #37
                Originally posted by LightBit View Post
                I love the README...

                Comment


                • #38
                  Originally posted by HyperDrive View Post
                  I love the README...
                  Its a good attitude to have right now considering the project just started haha
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #39
                    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.

                    Comment


                    • #40
                      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.

                      Comment

                      Working...
                      X