Announcement

Collapse
No announcement yet.

How Google's Android Maintains A Stable Linux Kernel ABI

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

  • #51
    Originally posted by coder View Post
    The problem with using Windows as an example is that some hardware says "works on Windows XP" (or pick your flavor of choice). Well, WinXP was supported for like 10 years or more. That's way longer than what I'm talking about.
    That the wrong point of windows history. You need to read Windows 3.5 NT and Windows 95 kernel ABI promise. Then you watch this be stretched. 3.5 NT and 95 kernel ABI stability was only meant to be until the service pack. As I said road paved with good intentions. What google is talking doing now is exactly what early Windows in fact promised and then due to pressure it grew out to 10+ years.

    Originally posted by coder View Post
    The other problem with Windows and Solaris is that the majority of your drivers are closed-source / out-of-tree. So, the coordination effort is much greater, whenever there's a desire to change something.
    Now yes. When both Windows and Solaris started ABI stability 95 percent of the drivers were in fact in tree of both windows and solaris.

    Originally posted by coder View Post
    With all that said, I think the real issue is that many who are opposed to any kind of ABI stability are (at least partially) using it as a lever against out-of-tree drivers. This will work, as long as Linux remains in a dominant position. As soon as that falters, it will be one element of Linux' undoing. I'd rather Linux evolve and remain relevant, but I won't go down with a sinking ship. I'd suggest those with a deeper stake in Linux' future take this issue more seriously.
    Its lack of abi stability that have forced a lot of drivers into Linux kernel mainline this was in effect before Linux kernel was in the current dominant position. ABI instability causing drivers to be mainline into the Linux kernel has nothing todo with dominant position. This shows you are just looking at current to make your point of view not looking back across the history.

    Those with a stake in Linux kernel future to take this serous-ally because its important that the kernel can change as hardware evolves this requires drivers to be able to change. If ABI on drivers means kernel space cannot change to match current day hardware it comes trouble very quickly.

    Originally posted by coder View Post
    I also feel like you have an agenda that you're not really disclosing.
    I do not have an agenda. I am specialist in forecasting outcomes by studying history. Part of this means you must compare apples with apples in timelines. So google is starting abi stablity you have to look when other groups attempted abi stablity at the start and see how well what google is offering aligns to this.

    My read on history could be wrong. But if google with their ABI stability plan has not read the history of the other that have done it the will not put in the required counters to adverse effects.

    Like one counter would be if you wish to use the google stable ABI for Linux you must also release the source code of that driver so it can be updated by someone else latter if the ABI ever has to change.

    Kernel ABI stablity + closed source driver hinders development really quickly. Remember libhybris and android user-space graphics drivers. This is not the first time google has created a stable driver ABI either prior ones were userspace with android. These closed source userspace drivers did end up coming a performance and security bottleneck.

    So google kernel driver ABI thing is also like kdbus as a solution to dbus-daemon problems that Linus said was a really bad idea.

    coder this is Google second attempt at doing a driver ABI for Linux. Track record of the prior one was basically a failure too.

    I remember nuse what was fuse modified for network devices that shows that userspace drivers can have the same performance as kernel base ones. These userspace driver-space interface also provide example of what happens as kernel space and stable driver ABI move out of alignment with each other design.

    Basically there is a lot of information that a stable kernel ABI driver is a bad idea. A lot of people forgot we have the fuse, cuse and nuse history to look at as well on what will happen to performance as the driver ABI and the kernel internal design goes out of alignment.

    Comment


    • #52
      Originally posted by skeevy420 View Post
      Huh. Well I'll be damned. Here I was thinking their method was to stick with old kernels.

      I don't think I have a single Android device that runs newer than 4.0.X and my current tablet and phone both run 3.1X (3.10 and 3.17).
      I have a smartphone with Android 8.1.0 which uses kernel v3.18 (compiled Aug 11th 2019 / gcc 4.8 / security patches Aug 1st 2019).

      Comment


      • #53
        Originally posted by c2p_ View Post

        I have a smartphone with Android 8.1.0 which uses kernel v3.18 (compiled Aug 11th 2019 / gcc 4.8 / security patches Aug 1st 2019).
        If my phone gets the update its Korean variants just received I'll have that kernel version too

        Comment


        • #54
          "Android Next Generation" aims to make kernel modules more portable between kernel images and devices.
          Really epic waste of manpower. And all that idiocy instead of joining efforts with upstream, mainlining stuff and then merely using latest shiny kernel + maybe eventually updating very few core system libs. This also ensures proper security fixes of all known vulns, bugs & so on, while bringing just some module ... hardly addresses that. And so instead of working on real solution Google joined epic windmill fight. Whoa.

          Originally posted by oiaohm View Post
          That the wrong point of windows history. You need to read Windows 3.5 NT and Windows 95 kernel ABI promise. Then you watch this be stretched. 3.5 NT and 95 kernel ABI stability was only meant to be until the service pack.
          Ahh at the end of day it f..d up ReactOS so well... poor copycats don't even know what particular subflavour of windows they try to mimic. At which point they end up with most windows drivers backfiring, he-he. I guess windows users could laugh on it ... but somehow when they dare to try major OS version upgrade it quickly turns them into crybabies, since quite often there is no driver for some of their hardware. Btw I had some funny success stories retrofitting "troubling" PCs with Linux instead of Windows - somehow Linux tends to be better about hardware support these days. It sounds funny, but, dammit, that's how world works these days. Attempt to use windows version other than pre-installed is quite an adventure with unknown outcome. It has been a major problem on mobile devices, but now it appears to be problem even on more common PCs and laptops as well. I dare to say MS killed off system programming for their OS really well - so now they can enjoy all the fruits it brings.
          Last edited by SystemCrasher; 09-20-2019, 08:23 PM.

          Comment

          Working...
          X