6 ms·

Another approach would be to go all in into improving the kernel [1] completely written in Rust, like in RedoxOS[2]. [1] https://gitlab.redox-os.org/redox-os/k

by xvilka 5y ago

Another approach would be to go all in into improving the kernel [1] completely written in Rust, like in RedoxOS[2]. [1] https://gitlab.redox-os.org/redox-os/kernel https://gitlab.redox-os.org/redox-os/kernel [2] https://www.redox-os.org/ https://www.redox-os.org/

5e92cb50239222b 5y ago
One of the main value propositions of Linux compared to any such alternative are thousands of drivers for almost any device that you can find on the market. Unless you find somebody willing to port them, I see very little practical sense in doing this (unless your goal is to have fun).
- Const-me 5y ago
  Moreover, for many critically important pieces of hardware, such as ARM Mali GPUs, the drivers are only available for Linux and Android.
- bo0tzz 5y ago
  Why not include support for running those 'legacy' C drivers in that new Rust kernel? Sure, you'd be giving up some of the memory guarantees, but that's no different from when you include some Rust into the current kernel.
  - rini17 5y ago
    There's no stable ABI for drivers. So much even Linux kernel itself isn't compatible with its drivers without their constant maintenance.
    - rcxdude 5y ago
      There's not even a stable API for drivers. The interfaces they use get changed and rewritten all the time.
      - phendrenad2 5y ago
        My pet conspiracy theory is they do this to discourage kernel forks, so that Linux doesn't become fragmented.
  - mariusor 5y ago
    I think supporting linux drivers was already tried in other kernels (I remember a talk Andrew Tanenbaum gave at a FOSDEM) when he tried to incorporate them in Minix v3 and he and his team gave up in frustration.
- quotemstr 5y ago
  I don't think we need as many kernel drivers as we have. Many of those drivers should never have been in the kernel in the first place. Userspace would have been adequate. If something can be done from userspace, it should be done from userspace. Legacy Linux drivers could be sandboxed in user space inside a fake Linux kernel environment, a bit like how captive NDIS used to provide a fake NT kernel for network drivers run under Linux.
  - mnd999 5y ago
    Sounds like you’re suggesting a microkernel architecture. It’s not a terrible idea, but it’s not a new one either and it hasn’t gained a huge amount of traction.
  - NavinF 5y ago
    Not practical. The Linux driver ABI is unstable. At best, your hypothetical microkernel will work on a subset of obsolete hardware.
    - quotemstr 5y ago
      Say you have a USB coffee maker with a custom kernel driver and you want to put that driver in userspace. Just take one specific kernel version that has that driver, build it as a microkernel (so the kernel runs as a user mode process) including that driver, and then make that driver talk to the rest of the system over a stable interface like dbus. (Think of something like UML.) The fact that the kernel ABI is unstable is irrelevant because you're not relying on ABI stability. You're using a specific version of the core kennel paired with a specific version of the driver.
      - NavinF 5y ago
        Ahh ic. That's very different from the example you gave, NDISwrapper (which does rely on the ABI stability of Windows drivers). Yeah your kernel could totally support USB coffee makers using USB passthrough to a Linux VM as long as (1) you write a Linux daemon for each device that lets you talk to the hardware over RPCs from the host and (2) all application software that wants to talk to said hardware uses your dbus API. That's a hell of an ask, but it's doable. But what about the xHCI drivers for USB? You still have to write that for every USB chip on the market. What about file systems? I've been burned by FUSE performance. What about GPU drivers? This sucks on Linux and it'll suck even harder on your hypothetical kernel. Or any device that sits on the PCIe bus for that matter. There are so many drivers that rely on running in a shared address space with data structures and hardware state shared with the rest of the kernel. At the very least you'll have to support the 2 new motherboard chipsets that come out every year. To be clear, I'm just taking about desktops. Laptops and phones will be a whole new world of pain
DeathArrow 5y ago
Aside for what others said, a microkernel is much less performant than a monolithic kernel.
- mnd999 5y ago
  I think post meltdown / spectre the idea of a trade off between security and performance has gained more traction. Perhaps it’s not such a problem.
- aliswe 5y ago
  I thought Fuchsia was a microkernel? not to counter your point.
zokula 5y ago
Shame about the license.

by xvilka 5y ago

5e92cb50239222b 5y ago

One of the main value propositions of Linux compared to any such alternative are thousands of drivers for almost any device that you can find on the market. Unless you find somebody willing to port them, I see very little practical sense in doing this (unless your goal is to have fun).

Const-me 5y ago
Moreover, for many critically important pieces of hardware, such as ARM Mali GPUs, the drivers are only available for Linux and Android.
bo0tzz 5y ago
Why not include support for running those 'legacy' C drivers in that new Rust kernel? Sure, you'd be giving up some of the memory guarantees, but that's no different from when you include some Rust into the current kernel.
- rini17 5y ago
  There's no stable ABI for drivers. So much even Linux kernel itself isn't compatible with its drivers without their constant maintenance.
  - rcxdude 5y ago
    There's not even a stable API for drivers. The interfaces they use get changed and rewritten all the time.
    - phendrenad2 5y ago
      My pet conspiracy theory is they do this to discourage kernel forks, so that Linux doesn't become fragmented.
- mariusor 5y ago
  I think supporting linux drivers was already tried in other kernels (I remember a talk Andrew Tanenbaum gave at a FOSDEM) when he tried to incorporate them in Minix v3 and he and his team gave up in frustration.
quotemstr 5y ago
I don't think we need as many kernel drivers as we have. Many of those drivers should never have been in the kernel in the first place. Userspace would have been adequate. If something can be done from userspace, it should be done from userspace. Legacy Linux drivers could be sandboxed in user space inside a fake Linux kernel environment, a bit like how captive NDIS used to provide a fake NT kernel for network drivers run under Linux.
- mnd999 5y ago
  Sounds like you’re suggesting a microkernel architecture. It’s not a terrible idea, but it’s not a new one either and it hasn’t gained a huge amount of traction.
- NavinF 5y ago
  Not practical. The Linux driver ABI is unstable. At best, your hypothetical microkernel will work on a subset of obsolete hardware.
  - quotemstr 5y ago
    Say you have a USB coffee maker with a custom kernel driver and you want to put that driver in userspace. Just take one specific kernel version that has that driver, build it as a microkernel (so the kernel runs as a user mode process) including that driver, and then make that driver talk to the rest of the system over a stable interface like dbus. (Think of something like UML.) The fact that the kernel ABI is unstable is irrelevant because you're not relying on ABI stability. You're using a specific version of the core kennel paired with a specific version of the driver.
    - NavinF 5y ago
      Ahh ic. That's very different from the example you gave, NDISwrapper (which does rely on the ABI stability of Windows drivers). Yeah your kernel could totally support USB coffee makers using USB passthrough to a Linux VM as long as (1) you write a Linux daemon for each device that lets you talk to the hardware over RPCs from the host and (2) all application software that wants to talk to said hardware uses your dbus API. That's a hell of an ask, but it's doable. But what about the xHCI drivers for USB? You still have to write that for every USB chip on the market. What about file systems? I've been burned by FUSE performance. What about GPU drivers? This sucks on Linux and it'll suck even harder on your hypothetical kernel. Or any device that sits on the PCIe bus for that matter. There are so many drivers that rely on running in a shared address space with data structures and hardware state shared with the rest of the kernel. At the very least you'll have to support the 2 new motherboard chipsets that come out every year. To be clear, I'm just taking about desktops. Laptops and phones will be a whole new world of pain

DeathArrow 5y ago

Aside for what others said, a microkernel is much less performant than a monolithic kernel.

mnd999 5y ago
I think post meltdown / spectre the idea of a trade off between security and performance has gained more traction. Perhaps it’s not such a problem.
aliswe 5y ago
I thought Fuchsia was a microkernel? not to counter your point.

zokula 5y ago

Shame about the license.