4 ms·

They did say: > One big challenge it addresses is Linux’s driver problem Android devices have been plagued with vendors having out-of-tree device drivers that

They did say: > 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.

aidenn0 2y ago
> 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. 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.
- plagiarist 2y ago
  I would love to have an open source microkernel OS that works as well as Linux on modern hardware even if the API wasn't stable. I am making assumptions that you could have ZFS and secure boot at the same time without jumping through hoops, containerization without needing fictitious UIDs for every user, and other things of that nature. The monolithic kernel is very frustrating with some things.
  - wilsonjholmes 2y ago
    Why does a monolithic kernel make those features have "hoops to jump through" compared with how a micro-kernel would handle those features?
  - aidenn0 2y ago
    The hoops that ZFS has to go through are twofold: licensing and unstable internal API. I don't see how a microkernel (on its own) fixes either of those things.
- amluto 2y ago
  > A monolithic kernel with a clearly defined device driver API would do the same thing. 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.
  - est31 2y ago
    It's still possible that drivers might be so buggy that a newer OS version might interact with them in a slightly different way which is still legal by the API definition but it still makes them crash or stop working.
    - vlovich123 2y ago
      That can be treated as an OS bug that’s fixed by updating the kernel to the latest version that fixes compat with that driver, which you can do because the driver remains unchanged. With Linux, even with DKMS, you’d need to backport your fixes to that old kernel in addition to maintaining the latest kernel version. And on mobile DKMS is not a thing.
      - xorcist 2y ago
        I believe you might be limited by your imagination just how bad out of tree third party drivers can be. We're talking about hardware with DMA access here. It's trivial to create a situation that can not be fixed in the kernel (without breaking other things). 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.
throwaway48476 2y ago
The point of linux is to upstream drivers so that devices just work.
- kyrra 2y ago
  The problem is the release cadence, especially around mobile devices. Driver packages for them tend to be worked on right up to shipping, because they are developed in parallel with the 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.
  - throwaway48476 2y ago
    In PC land linux driver support is not always day one as they are working on the drivers up to and sometimes after the release. Somehow the mobile vendors aren't capable of this.
    - pjmlp 2y ago
      OEMs would rather sell new devices that do updates for free. 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 https://download.lenovo.com/eol/index.html
    - pantalaimon 2y ago
      On the PC a lot more is handled by the UEFI firmware so you need a lot less device specific drivers.
  - yencabulator 2y ago
    The problem, especially around mobile devices, is that the vendors only care about a single-time sale. They just fork a specific kernel release, take a chainsaw to it until it stops crashing on their device, and try to never touch the source again. Very few hardware vendors put money into having maintainable drivers, because the next gadget they ship might have different chips in it, and the chips come from a subcontractor anyway.
mdhb 2y ago
It’s also a totally different security architecture that is considered actually defendable rather than the cat and mouse game we have going on today. It’s actually well designed for modern threats.
Fluorescence 2y ago
> 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 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.
surajrmal 2y ago
It's worth mentioning that fuchsia doesn't currently actually offer a stable driver abi. Or at least not one that is stable for more than a few months.

aidenn0 2y ago

> 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. 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.

plagiarist 2y ago
I would love to have an open source microkernel OS that works as well as Linux on modern hardware even if the API wasn't stable. I am making assumptions that you could have ZFS and secure boot at the same time without jumping through hoops, containerization without needing fictitious UIDs for every user, and other things of that nature. The monolithic kernel is very frustrating with some things.
- wilsonjholmes 2y ago
  Why does a monolithic kernel make those features have "hoops to jump through" compared with how a micro-kernel would handle those features?
- aidenn0 2y ago
  The hoops that ZFS has to go through are twofold: licensing and unstable internal API. I don't see how a microkernel (on its own) fixes either of those things.
amluto 2y ago
> A monolithic kernel with a clearly defined device driver API would do the same thing. 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.
- est31 2y ago
  It's still possible that drivers might be so buggy that a newer OS version might interact with them in a slightly different way which is still legal by the API definition but it still makes them crash or stop working.
  - vlovich123 2y ago
    That can be treated as an OS bug that’s fixed by updating the kernel to the latest version that fixes compat with that driver, which you can do because the driver remains unchanged. With Linux, even with DKMS, you’d need to backport your fixes to that old kernel in addition to maintaining the latest kernel version. And on mobile DKMS is not a thing.
    - xorcist 2y ago
      I believe you might be limited by your imagination just how bad out of tree third party drivers can be. We're talking about hardware with DMA access here. It's trivial to create a situation that can not be fixed in the kernel (without breaking other things). 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.

throwaway48476 2y ago

The point of linux is to upstream drivers so that devices just work.

kyrra 2y ago
The problem is the release cadence, especially around mobile devices. Driver packages for them tend to be worked on right up to shipping, because they are developed in parallel with the 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.
- throwaway48476 2y ago
  In PC land linux driver support is not always day one as they are working on the drivers up to and sometimes after the release. Somehow the mobile vendors aren't capable of this.
  - pjmlp 2y ago
    OEMs would rather sell new devices that do updates for free. 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 https://download.lenovo.com/eol/index.html
  - pantalaimon 2y ago
    On the PC a lot more is handled by the UEFI firmware so you need a lot less device specific drivers.
- yencabulator 2y ago
  The problem, especially around mobile devices, is that the vendors only care about a single-time sale. They just fork a specific kernel release, take a chainsaw to it until it stops crashing on their device, and try to never touch the source again. Very few hardware vendors put money into having maintainable drivers, because the next gadget they ship might have different chips in it, and the chips come from a subcontractor anyway.

mdhb 2y ago

It’s also a totally different security architecture that is considered actually defendable rather than the cat and mouse game we have going on today. It’s actually well designed for modern threats.

Fluorescence 2y ago

> 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 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.

surajrmal 2y ago

It's worth mentioning that fuchsia doesn't currently actually offer a stable driver abi. Or at least not one that is stable for more than a few months.