Announcement

Collapse
No announcement yet.

BUS1, The Successor To KDBUS, Formally Unveiled -- Aiming For Mainline Linux Kernel

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

  • #11
    Here is a very good article about BUS1, which also compares it with binder. It also explains that BUS1 only implements the very basic elements for a multicast IPC inside the kernel space, but needs some user space elements to be really useful. This is the fact that, IMHO, could help to make it merged in the kernel source.

    https://lwn.net/Articles/697191/

    Comment


    • #12
      Originally posted by 89c51 View Post

      Could someone explain how wayland is involved with bus1? Does he mean rewrite of wayland to look more like bys1?
      I think it was meant that Wayland uses at the lowest level very similar communication mechanism, that could be simply reimpleented with BUS1.



      Comment


      • #13
        Originally posted by yoshi314 View Post
        the problem was that it did not solve the problem it was supposed to solve (performance), and was completely insecure. it was far from perfect replacement.
        it was faster than dbus and it was not less secure, so it was perfect replacement
        Originally posted by yoshi314 View Post
        i think that coupling bus1 with some userspace compatibility wrapper that would act as a drop in replacement for dbus would also serve as a perfect replacement. assuming that bus1 is well designed and passes the review.
        i think you didn't watch presentation

        Comment


        • #14
          Originally posted by staalmannen View Post
          So will it be possible to implement binder on top of bus1 so that another big diff between mainline and Android can be removed?
          yes, it will

          Comment


          • #15
            Originally posted by pal666 View Post
            Originally posted by staalmannen View Post
            So will it be possible to implement binder on top of bus1 so that another big diff between mainline and Android can be removed?
            yes, it will
            What are you talking about? (Open)Binder (it comes from Be, Inc famous of BeOS, then Palm Inc. bought Be, Inc.) has been part of Linux kernel since years and became stable in February 2015.

            Why should binder exist? What about making a common solution instead bloating the kerne with more subsystems from different Linux-based pseudo-propietary distributions?

            This is worse than forking! It's a f$$$g mess!

            Originally posted by https://kernelnewbies.org/Linux_3.19#head-fa49268d45ce9bae2e47c5a75ef0333947fa18a6
            1.4. Android binder moved to stable

            The Android binder code has been placed in the "staging" are of the kernel for a long time. The code, however, has been stable for many years now and it has been shipped in millions of phones. There has been reticences over binder, but no matter what comes in the future, Linux is going to have to support this API anyway, so might as well move it to the "real" part of the kernel.

            Code: commit

            Comment


            • #16
              Originally posted by timofonic View Post

              What are you talking about? (Open)Binder (it comes from Be, Inc famous of BeOS, then Palm Inc. bought Be, Inc.) has been part of Linux kernel since years and became stable in February 2015.

              Why should binder exist? What about making a common solution instead bloating the kerne with more subsystems from different Linux-based pseudo-propietary distributions?

              This is worse than forking! It's a f$$$g mess!
              Because binder doesn't do any of the things bus1 does, and which it is intended for. Primarily multicast, the fact that underlying mechanics operate similar to the uni-cast binder would a point in its favor. Also that it avoid the terrible design choices of binder like global locks is another.

              Comment


              • #17
                Originally posted by carewolf View Post

                Because binder doesn't do any of the things bus1 does, and which it is intended for. Primarily multicast, the fact that underlying mechanics operate similar to the uni-cast binder would a point in its favor. Also that it avoid the terrible design choices of binder like global locks is another.

                So why about Android ditching Binder and use DBUS1 instead?

                Comment


                • #18
                  Originally posted by timofonic View Post


                  So why about Android ditching Binder and use DBUS1 instead?
                  They wouldn't "ditch" Binder because too much 3rd-party userland code depends on those APIs... but they might scrape out its guts and replace them with BUS1, similar to how kdbus would have presented the libdbus APIs but been a different beast under the hood.

                  Comment


                  • #19
                    Originally posted by ssokolow View Post

                    They wouldn't "ditch" Binder because too much 3rd-party userland code depends on those APIs... but they might scrape out its guts and replace them with BUS1, similar to how kdbus would have presented the libdbus APIs but been a different beast under the hood.
                    What kind of userland code? Isn't Android based on Java framework and their own API? Do they expose Binder to userland? :O

                    Comment


                    • #20
                      Originally posted by timofonic View Post

                      What kind of userland code? Isn't Android based on Java framework and their own API? Do they expose Binder to userland? :O
                      From what I've heard, the big reason they eventually had to merge Binder's "relies on quirks of Android's userland to be safe to use" kernel-side code rather than rebasing it on something else is that Binder's mixture of call semantics and performance characteristics, which does affect how your Java code is written, couldn't be replicated on top of any of the existing kernel IPC solutions.

                      (By call semantics, I mean details like blocking vs. non-blocking, what level of ordering constraints between calls (none, same process, same sender to all processes, etc.) are guaranteed, etc.)

                      Comment

                      Working...
                      X