Announcement

Collapse
No announcement yet.

BUS1 Didn't Land This Year, But It's Making Progress

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

  • BUS1 Didn't Land This Year, But It's Making Progress

    Phoronix: BUS1 Didn't Land This Year, But It's Making Progress

    What you will not find as part of the list of new Linux 4.10 kernel features is BUS1, the successor to the un-merged KDBUS initiative and a new approach for in-kernel IPC. While it didn't land in 2016 to the mainline kernel, it's making progress...

    http://www.phoronix.com/scan.php?pag...ssing-For-2017

  • #2
    Can somebody explain the point of BUS1? Wasn't the reason for KDBUS to move DBUS to the kernel for speed/security reasons, and make it so that nobody has to re-write their programs? If BUS1 is different than DBUS, it completely defeats the entire point of the venture.

    Comment


    • #3
      Yes, but Linus will never ever accept kdbus upstream because it is bad by design (and it has to if it wants to be retro compatible), so they had to write a completely new protocol.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        Originally posted by darkbasic View Post
        Yes, but Linus will never ever accept kdbus upstream because it is bad by design (and it has to if it wants to be retro compatible), so they had to write a completely new protocol.
        My point then becomes: why would Linus accept THIS protocol upstream when there isn't a reason for it anymore? It's JustAnotherIPC at this point

        Comment


        • #5
          Originally posted by Daktyl198 View Post
          Can somebody explain the point of BUS1? Wasn't the reason for KDBUS to move DBUS to the kernel for speed/security reasons, and make it so that nobody has to re-write their programs? If BUS1 is different than DBUS, it completely defeats the entire point of the venture.
          kdbus had a security flaw that couldn't be fixed. A new API had to be created, and while at it, the requirement to cater to dbus was dropped and now bus1 is a general purpose API.

          Comment


          • #6
            Originally posted by Daktyl198 View Post

            My point then becomes: why would Linus accept THIS protocol upstream when there isn't a reason for it anymore? It's JustAnotherIPC at this point
            Because it's aiming to be a half-way between full-fleshed APIs like D-Bus and primitives like "seal memory" that can eventually become "The one true in-kernel IPC" which future IPC systems are built upon. (eg. I believe I remember seeing in a talk that one hope is that Binder can be rebased upon it.)

            Comment


            • #7
              Originally posted by ssokolow View Post

              Because it's aiming to be a half-way between full-fleshed APIs like D-Bus and primitives like "seal memory" that can eventually become "The one true in-kernel IPC" which future IPC systems are built upon. (eg. I believe I remember seeing in a talk that one hope is that Binder can be rebased upon it.)
              This would make sense. AFAICT the philosophy of Linux (as opposed to some other kernels, notably NT and also FreeBSD) has always been to expose very low level APIs and let features that are actually usable be implemented in userland on top of them. The question is then, why do we need BUS1? Why can't D-Bus be rewritten to use memory seals instead?

              Comment


              • #8
                what's the purpose of kdbus dbus bus1!?
                Last edited by Azrael5; 27 December 2016, 05:44 AM. Reason: corrections

                Comment


                • #9
                  Originally posted by Azrael5 View Post
                  what's the purpose of kdbus dbus bus1!?
                  Isn't it obvious ?
                  bus2.

                  Comment


                  • #10
                    Originally posted by Brane215 View Post

                    Isn't it obvious ?
                    bus2.
                    ok I understand so we'll wait for bus3

                    I feel this API concern with free cache memory operation. Right?
                    Last edited by Azrael5; 27 December 2016, 06:10 AM. Reason: integration

                    Comment

                    Working...
                    X