Thanks for the info. For those of us not familiar with it, what were the main motivations for building Fuchsia instead of just using Linux?
> One big challenge it addresses is Linux’s driver problem
Android devices have been plagued with vendors having out-of-tree device drivers that compile for linux 3.x, but not 4.x or 5.x, and so the phone is unable to update to a new major android version wit ha new linux kernel.
A micro-kernel with a clearly defined device driver API would mean that Google could update the kernel and android version, while continuing to let old device drivers work without update.
That's consistently been one of the motivating factors cited, and linux's monolithic design, where the internal driver API has never been anything close to stable, will not solve that problem.
A monolithic kernel with a clearly defined device driver API would do the same thing. Linux is explicitly not that, of course. Maintaining backwards-compatibility in an API is a non-trivial amount of work regardless of whether the boundary is a network connection, IPC, or function call.
Maybe, but I doubt it. History has shown pretty clearly that driver authors will write code that takes advantage of its privilege state in a monolithic kernel to bypass the constraints of the driver API. Companies will do this to kludge around the GPL, to make their Linux driver look more like the Windows driver, because they were lazy and it was easier than doing it right, and for any number of other reasons. The results include the drivers failing if you look at the rest of the system funny and making the entire system wildly insecure.
If you want to a driver not subject to competent code review abide by the terms of the box in which it lives, then the system needs to strictly enforce the box. Relying on a header file with limited contents will not do the job.
Well, your job is shipping the driver. If the API is limited and/or your existing drivers in Windows or other OSs do something and the linux driver doesn't then you have a problem
Linux kernel pros: it evolves organically
Linux kernel cons: it evolves organically
If you are running some generic PC hardware to write this comment, chances are that at least one tiny part somewhere which is dependent on some specific obscure timing to come up properly which just happens to work because someone inserted a small delay somewhere.
The same printer works with Linux the same it has always done. But that's not Windows' fault or to Linux's credit. It's just the result of a really crappy vendor. However the Linux API is generally more stable than people give it credit for, it's just that it's the C headers only. Anything compiled for a kernel generally won't work anywhere else, and that's not what the crappy vendors wants.
In the embedded space, including most mobile phone vendors which seemed to be an important use case for Fuchsia, even reputable vendors will generally give you an image of an operating system heavily modified to work with their hardware. That's their "driver". Imagine buying a new PC and receiving a DVD with a Windows modified to work on that hardware only. Of course you can't upgrade or even patch security issues beyond what the vendor will give you! You're supposed to buy new hardware. Sure, you could extract the drivers and try to install them on a vanilla Windows, and that's exactly what projects like LineageOS do, but most users won't bother.
That's the situation with phones. It's not at all clear why Fuchsia thinks they could solve this. It's a cultural and an economical problem and can't be fixed with software alone. Why would phone manufacturer care about your microkernel architecture? They will just patch the whole operating system, binaries and everything, until it boots enough to start the GUI and ship that. Just like they always have.
The only thing that could improve this situation is by enforcing the GPL, or have similar contractual stipulations like only being allowed to ship a reference implementation unmodified, but Google shows no interest in doing that. They care about getting Android on as many devices as possible with no regard to their respective quality or product longevity.
https://en.wikipedia.org/wiki/Windows_Driver_Model
https://en.wikipedia.org/wiki/Windows_Display_Driver_Model
Naturally, as you point out, it can do nothing against forced obsolence if the the OEM expliciltly tied the driver to check the Windows version.
However, if you discover that the box was insufficient at any point, you have to choose between changing the box (and breaking some perfectly good drivers), or leaving the insufficient box in place. API versioning can let you delay this decision to reduce pain, but it will happen at some point.
FWIW, I'm hugely in favor of microkernels, but they are a lead bullet (which we need lots of), not a silver bullet for these sorts of problems.
What's preventing adding a driver compatibility layer over the unstable API? I would accept a some performance cost and NOPs for new features using a shim for existing legacy binary drivers compared to being forced to junk functioning hardware.
Android using the absolutely most head or tip version of the Linux kernel sounds like a QA nightmare of its own.
Mobile SOC has to have everything to start up the phone, as there is no bios like system that the driver is kind work through. Maybe this is a problem that could be solved, but it hasn't been yet.
The same happens in PC land with laptops, you seldom get drivers from Microsoft for laptop specific components, those come from the OEM, and get you what you get.
For example, https://download.lenovo.com/eol/index.html
(Historically, that's one big reason that there's lots of Android phones that get a fork of whatever release was current some months before they shipped, and never get substantial updates.)
So many GPL violations in the Android world currently
1. Control. It's pretty awkward if your main product depends on an open source community who might say "no" (or "fuck off you worthless imbecile") to half the things you want. You'll end up with a fork (they did!) which has serious downsides.
2. Stable driver ABI.
3. Modern security design. A microkernel, and Rust is used extensively.