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 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


    • #32
      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


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


        • #34
          https://github.com/gregkh/kdbus

          Comment


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

            Comment


            • #36
              Originally posted by HyperDrive View Post
              I love the README...
              Its a good attitude to have right now considering the project just started haha

              Comment


              • #37
                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


                • #38
                  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


                  • #39
                    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.
                    If I remember correctly, D-Bus was (still is?) about 17 times *slower* than ORBit (CORBA), so it needs all the help it can get...

                    Comment


                    • #40
                      Originally posted by HyperDrive View Post
                      If I remember correctly, D-Bus was (still is?) about 17 times *slower* than ORBit (CORBA), so it needs all the help it can get...
                      Agreed, it's a POS. But if you profile a typical DBUS transaction you'll see that a ton of time is sucked up in the userland libraries, not just in the daemon itself. Developing a new message transport in the kernel isn't going to magically improve the overall performance, the libraries still suck.

                      Comment

                      Working...
                      X