3 ms·

Instead of a moonshot micro kernel, why didn't Google just build and maintain a new Linux driver API/ABI layer with backwards compatibility and security? Not an

Instead of a moonshot micro kernel, why didn't Google just build and maintain a new Linux driver API/ABI layer with backwards compatibility and security? Not an easy endeavor, but is it harder than Fuchsia?

amluto 2y ago
Yes. If you want a nice, secure driver model, a greenfield project is much easier. Maybe one could run a Fuchsia-like thing inside Linux and use Linux to provide the Linux userland ABI, but that might be challenging to maintain.
okanat 2y ago
It is more moonshot to design an API while Linux devs are constantly pulling the rug under. Microkernels provide nice secure API boundaries and optimizations to reduce performance impact when crossing them on modern CPUs. The monolithic design forces you to stay in either user or kernel mode as much as possible to not lose performance. Adding the API and ABI incompatibility makes it near impossible to maintain. It will require a hard fork of Linux, which won't be Linux anymore. Monolithic design is the artifact of low-register-count CPUs of the past. If you are going to create a hard fork of a kernel, why not use a more modern design anyway?
- ranguna 2y ago
  You have to wonder why the Linux devs are "pulling the rug under"
  - kevin_thibedeau 2y ago
    They want to keep control. Same reason RMS opposed exposing GCC internals for non-free use.
  - simoncion 2y ago
    If you get your driver into the mainline kernel, it gets maintained. If your driver is not in mainline, then you have to deal yourself with kernel internals changing. Hell, a while back one of the kernel devs was actively screaming for hardware manufacturers to reach out to them so folks could work with the manufacturer to get drivers for their products into mainline. There was even a website and nice instructions on what to do and who to contact... but I'll be fucked if I can find it anymore. There's nothing nefarious going on... it's explicitly stated (and well-known) that the stable interface to Linux is the userspace interface. Inside the kernel, things are subject to change at any time. Don't want to have to work to keep up? Get your driver into mainline!
saidinesh5 2y ago
Google kind of does this with Android. Most of the magic sauce for a lot of hardware is in user space - https://siliconsignals.io/blog/implementing-custom-hardware-abstraction-layer-hal-in-android-with-aidl-silicon-signals/ https://siliconsignals.io/blog/implementing-custom-hardware-... That's why you used to not touch vendor partition when flashing a custom ROM etc..
tonfa 2y ago
Was it what project treble was about? https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html https://android-developers.googleblog.com/2017/05/here-comes...
jhasse 2y ago
Because they get the bonus of no GPL and owning the copyright as a bonus with Fuchsia.

amluto 2y ago

Yes. If you want a nice, secure driver model, a greenfield project is much easier. Maybe one could run a Fuchsia-like thing inside Linux and use Linux to provide the Linux userland ABI, but that might be challenging to maintain.

okanat 2y ago

It is more moonshot to design an API while Linux devs are constantly pulling the rug under. Microkernels provide nice secure API boundaries and optimizations to reduce performance impact when crossing them on modern CPUs. The monolithic design forces you to stay in either user or kernel mode as much as possible to not lose performance. Adding the API and ABI incompatibility makes it near impossible to maintain. It will require a hard fork of Linux, which won't be Linux anymore. Monolithic design is the artifact of low-register-count CPUs of the past. If you are going to create a hard fork of a kernel, why not use a more modern design anyway?

ranguna 2y ago
You have to wonder why the Linux devs are "pulling the rug under"
- kevin_thibedeau 2y ago
  They want to keep control. Same reason RMS opposed exposing GCC internals for non-free use.
- simoncion 2y ago
  If you get your driver into the mainline kernel, it gets maintained. If your driver is not in mainline, then you have to deal yourself with kernel internals changing. Hell, a while back one of the kernel devs was actively screaming for hardware manufacturers to reach out to them so folks could work with the manufacturer to get drivers for their products into mainline. There was even a website and nice instructions on what to do and who to contact... but I'll be fucked if I can find it anymore. There's nothing nefarious going on... it's explicitly stated (and well-known) that the stable interface to Linux is the userspace interface. Inside the kernel, things are subject to change at any time. Don't want to have to work to keep up? Get your driver into mainline!

saidinesh5 2y ago

Google kind of does this with Android. Most of the magic sauce for a lot of hardware is in user space - https://siliconsignals.io/blog/implementing-custom-hardware-abstraction-layer-hal-in-android-with-aidl-silicon-signals/ https://siliconsignals.io/blog/implementing-custom-hardware-... That's why you used to not touch vendor partition when flashing a custom ROM etc..

tonfa 2y ago

Was it what project treble was about? https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html https://android-developers.googleblog.com/2017/05/here-comes...

jhasse 2y ago

Because they get the bonus of no GPL and owning the copyright as a bonus with Fuchsia.