Announcement

Collapse
No announcement yet.

How Google's Android Maintains A Stable Linux Kernel ABI

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

  • #11
    tg--
    What good is it to have stable ABIs just to allow derived code to live outside of the project, just to allow external - possibly license-infringing - code to influence the kernel itself, by forcing it to maintain code that wouldn't otherwise be maintained?
    Seeing as how the current model is "oh, that project uses this part of the kernel so let's wall it off or remove that part" means that possible license infringing code is already influencing the kernel itself. A stable API means that an external project has to work within the limitations of the API versus use what's available until it isn't and needs to be fixed.

    Do you honestly think that the kernel devs would have tweaked the GPL_EXPORTS if it weren't for ZoL? A stable API would have had what's supposed to be used by what set in stone years ago with revisions to the API set to go into effect with new LTS kernels. Like, 4.14 would have introduced something new or changed something old and all the kernels from there to the very last 4.18 release would be expected to respect that without a single tweak until 4.19.

    If a stable API was actually the case, the ZoL people would have known what is good to use, what is safe, what is set in stone, what will be removed soon, etc. Extend that to an entire OS and Google making Fuchsia makes a lot of sense. A stable API would also mean that the kernel devs can say "if you don't hook into our kernel using these methods then you're in violation" whereas the current method is a cat and mouse free-for-all that ZoL and Nvidia users know all too well.

    Comment


    • #12
      Originally posted by DanL View Post
      They intend to write their own kernel? Where did you see that? They modify the upstream Linux kernel. That is not the same thing as writing a new one. It's not even close. I'm sorry if that runs counter to your "Linux sucks" narrative.
      I believe it's a reference to the hypothesizing that Fuchsia is intended to be a successor to Android, taking advantage of how guidelines-compliant Android apps stick to ABIs that have no dependence on the Linux kernel.

      Comment


      • #13
        Originally posted by DanL View Post

        They intend to write their own kernel? Where did you see that?
        He's probably talking about Fuchsia and Zircon.

        Comment


        • #14
          birdie i have to agree with you. i have a nvidia gpu and i know the problem of drivers not working with newer kernel. and of course opensource fanatics will tell that nvidia its at fault for not helping with opensource driver. its a must for drivers to be opensource otherwise we ran into problems with kernels. so kernel is not at fault here. just the driver

          Comment


          • #15
            Originally posted by birdie View Post
            God, I thought rabid open source fans will start pouring tons of shat right after my comment but it just happened so fast it took me by surprise, lol. I will now gladly leave this thread 'cause it's already been hijacked by bigotry and absence of any rationale.


            Comment


            • #16
              Originally posted by loganj View Post
              birdie i have to agree with you. i have a nvidia gpu and i know the problem of drivers not working with newer kernel. and of course opensource fanatics will tell that nvidia its at fault for not helping with opensource driver. its a must for drivers to be opensource otherwise we ran into problems with kernels. so kernel is not at fault here. just the driver
              Only Nvidia fanatics will defend this crap company and their shitty blobs. I hope Linux will break ABI all the time, so those monkeys will have more work to do.

              Comment


              • #17
                Originally posted by skeevy420 View Post
                Seeing as how the current model is "oh, that project uses this part of the kernel so let's wall it off or remove that part" means that possible license infringing code is already influencing the kernel itself. A stable API means that an external project has to work within the limitations of the API versus use what's available until it isn't and needs to be fixed.
                Part of the problem here back in the 1990s there was a idea of making kernel drivers that could be used by Linux, Freebsd and Unix systems this would have been the stable ABI you would be talking about. But due to the abstraction overhead that kept the ABI nice and stable on performance very few drivers were made for it.

                Stable ABI=slow because you have to maintain that compatibility by doing longer code paths.

                Maybe this time around Google will be successful.

                Originally posted by skeevy420 View Post
                Do you honestly think that the kernel devs would have tweaked the GPL_EXPORTS if it weren't for ZoL?
                Without question yes. There were other areas changes to GPL_EXPORTS around the same time that no third party module used it a form of multi core performance tweak for real-time Linux support. Its todo with they type of protection that was wrapped around those parts falls under a patent who license is only granted for GPLv2 usage.

                Linux kernel has trademarks, Copyright and Patents that you have to consider. Yes some of the patent usage licenses say this is free to use as long as your stuff is GPLv2 and at times this ruins third party drivers day.

                skeevy420 there was a wacky one back in 2008 when the reason why a symbol was GPL_EXPORT and not usable by Nvidia binary blob was because Nvidia has given the patent to the Linux kernel as GPLv2 only. That end up being a straight forward fix of Nvidia providing the right paper work to legal at the Linux foundation. Float point one not that simple.



                Please note this is 2003. Linus has always been very clear you should avoid floating point in kernel space at all costs. Also not all platforms Linux runs on has float point so no kernel space float point functions should not have been driver don't build. Driver run slow yes. Driver not run due to no float point functions the driver is defective because kernel space driver source code should not expect to find floating point.

                Comment


                • #18
                  Originally posted by Volta View Post
                  I hope Linux will break ABI all the time, so those monkeys will have more work to do.
                  and let the user enjoy his time reinstalling the driver.

                  Comment


                  • #19
                    Originally posted by DanL View Post

                    They intend to write their own kernel? Where did you see that?
                    If they're not writing their own kernel, then I guess Zircon is fake?

                    Comment


                    • #20
                      If only they would try to provide a stable ABI or API for Chromium, or just any of the Chromium subprojects.

                      Comment

                      Working...
                      X