Announcement

Collapse
No announcement yet.

Staging Driver Changes For Linux 3.19: Android Binder Code Leaves Staging

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

  • Staging Driver Changes For Linux 3.19: Android Binder Code Leaves Staging

    Phoronix: Staging Driver Changes For Linux 3.19: Android Binder Code Leaves Staging

    The latest Linux 3.19 kernel changes to talk about is the staging pull request that was sent in a short time ago by Greg Kroah-Hartman...

    http://www.phoronix.com/vr.php?view=MTg2NDA

  • #2
    Oh, wow, so the binder code did make it into mainline after all? I thought the kernel devs hated its concept.

    Comment


    • #3
      Originally posted by Ancurio View Post
      Oh, wow, so the binder code did make it into mainline after all? I thought the kernel devs hated its concept.
      See this:
      https://www.youtube.com/watch?v=yRvHq-HTJ7g

      and this:

      https://plus.google.com/+gregkroahha...ts/JG5K9Tkfim3
      http://kroah.com/log/blog/2014/01/15/kdbus-details/

      Comment


      • #4
        Well, those references just said that kdbus will likely never be able to serve as a binder implementation base.
        My assumption that kernel developers were not very favored towards it might be a bit outdated, it's mostly based on this information: http://elinux.org/Android_Binder

        Comment


        • #5
          Originally posted by Ancurio View Post
          Well, those references just said that kdbus will likely never be able to serve as a binder implementation base.
          My assumption that kernel developers were not very favored towards it might be a bit outdated, it's mostly based on this information: http://elinux.org/Android_Binder
          Essentially they still don't. Having said that, something being used by millions of devices requires some level of pragmatic compromises.

          Comment


          • #6
            I was really hoping those palmos folks in google would leave so binder could be exchanged for something better (the fact that binder is lighter is a non-issue with the devices android is capable of running on today). IIRC, there've been two security issues that were the direct result of binder's mechanism.

            Comment


            • #7
              Delta?

              I am curious to know how big the remaining delta is between Android Linux and Linus' Linux after this merge. I look forward to the day when one simply can run the latest-and-greatest mainline kernel as alternative kernel on your Android phone (and in order to be able to do that - one need to be able to compile in the blob drivers and I believe binder is a critical part of that).

              Comment


              • #8
                Originally posted by staalmannen View Post
                I am curious to know how big the remaining delta is between Android Linux and Linus' Linux after this merge. I look forward to the day when one simply can run the latest-and-greatest mainline kernel as alternative kernel on your Android phone (and in order to be able to do that - one need to be able to compile in the blob drivers and I believe binder is a critical part of that).
                Binder is an IPC mechanism. It really doesn't have anything specific to do with blob drivers. The major issue preventing you from running mainline kernel on an Android device has always been, and will remain (for the time) the hardware specific drivers and initialization processes, which by and large, ARE open source (they are legally required to be under GPL), but far from acceptable for inclusion in mainline linux due to (a) poor quality, (b) philosophical barriers due to a lack of open source userspace drivers available for them. You should think of the blob Android device drivers in the same way as you think of the blob nvidia GPU drivers. Open source shim with a massive ugly blob.

                Having said that, if you keep your targets set on more mainstream type hardware (desktops, laptops, etc.), you *can currently* run an off-the-shelf conventional computer with an AMD or Intel GPU on a completely open source Android software stack (I mean, of course, aside from a few firmware blobs...), including 3d accel via Mesa/Gallium3d. As far as I have looked (frankly, not too deeply...), Android-x86 is tracking mainline.

                Comment

                Working...
                X