4 ms·

Seems like a lot of alternative OSs these days are microkernels. Fuchsia/Zircon, Redox, and now this. Seems pretty interesting. I wonder if the Linux kernel wil

Seems like a lot of alternative OSs these days are microkernels. Fuchsia/Zircon, Redox, and now this. Seems pretty interesting. I wonder if the Linux kernel will take cues from these developments and start shoving auxiliary device drivers into userspace? A pleb can dream.

ungamedplayer 4y ago
FUSE for filesystems already exists in userspace, so its not unheard of. Just making it work safely and secure is the first steps to having these kinds of features upstreamed.
SkyMarshal 4y ago
> Fuchsia/Zircon, Redox, and now this. Don't forget the original (for Linux anyway), SEL4. https://sel4.systems https://sel4.systems
- senko 4y ago
  seL4 has nothing to do with Linux, aside from the fact that the team was involved in another Linux-on-top-of-L4 project (L4Linux). Also, seL4 comes from a long line of L4 microkernels (https://en.wikipedia.org/wiki/L4_microkernel_family#History https://en.wikipedia.org/wiki/L4_microkernel_family#History) which actually predates Linux (L3 was developed back in '88).
survirtual 4y ago
You can already build auxiliary drivers / codecs / etc and insert them into modules, then put together a device tree overlay to use the module. With things like dt overlay fs, straight forward to insert new device trees. If you really wanted, could build a minimal kernel and move many devices to be inserted at runtime. Anyway, wouldn’t mind if all that was made a lot smarter and made more accessible to people.
- blooalien 4y ago
  Isn't that how Raspberry Pi does things?
  - survirtual 4y ago
    It is.
- kelnos 4y ago
  That's not a microkernel architecture; that's a monolithic kernel with modules. (Just like Linux.)
  - survirtual 4y ago
    I’m talking about linux responding to the comment about it.
Santosh83 4y ago
Linus is not a great believer in the microkernel architecture. Quite apart from that while certain things like FS can be shifted to userspace through FUSE, a ground-up rearchitecting into a microkernel may be extremely difficult for Linux at this stage. It would be more or less a rewrite of most of the core kernel I guess... and then the question of changes to the syscalls, which also Linus doesn't encourage.
- jacquesm 4y ago
  What Linus believes in or does not believe is hardly relevant though, what matters is what is the best solution going forward. Sunk costs are always smaller than the future costs.
- CameronNemo 4y ago
  Linus was not a believer something like 20 years ago. I wouldn't be surprised if his stance has significantly softened.
- torginus 4y ago
  Generally his skepticism was driven by 2 things around the time the microkernel debate happened: - Microkernels need more development effort for equal functionality, something that was a constraint when he was doing Linux on his own. - The context switching penalties on 386s were ginormous - it's much more reasonable now, I'd even say it's not much more penalizing than thread switching. - We live in a multi-master world with IOMMU - tons of devices have virtual address spaces on their own, with most of them doing DMA transfers.
pjmlp 4y ago
The monolithic kernel has lost, only the FOSS UNIX clones haven't yet catch up to it. OS X and Windows always had a hybrid architecture since the beginning, and with the push for user space drivers for third parties even more so. Most commercial RTOS are microkernel based, like QNX and INTEGRITY. Even Android imposes a fake microkernel like architecture since Project Treble, where since Android 8 classical Linux drivers are considered "legacy". Then there is the whole irony that those that strongly argue for monolithic kennels, nowadays run Linux on top of a type 1 hypervisor, full of containers.
- tialaramex 4y ago
  > OS X and Windows always had a hybrid architecture since the beginning "Hybrid architecture" is a PR exercise. These are monolithic designs with a better marketing team. Imagine if somebody tells you their new programming language has a "hybrid" numeric type. It has all the advantages of floating point numbers, yet none of the disadvantages of the integer types. Wow! Wait, hang on, let's look a bit more closely, those are floats. They've just described floats, but used some semantic sleight of hand to claim they're a "hybrid" numeric type.
  - pjmlp 4y ago
    Some like to call it a PR exercise. Others enjoy that there is some effort in place to have RPC comunnication between kernel modules instead of direct function calls, a hard push for third party drivers only to exist in userspace and a standard ABI for extensions. I rather see the progress side, even if partial, than hold to legacy designs. See I could also call a PR exercise to safe languages that depend on using unsafe everywhere on their lower layers, maybe they aren't safe after all. And yet we know that isn't the case.
    - tialaramex 4y ago
      > See I could also call a PR exercise to safe languages that depend on using unsafe everywhere on their lower layers, maybe they aren't safe after all. Although it's easier to look at what's technically different in a language like Rust, probably more important is a philosophical difference and the resulting community. Let's use an example I gave recently to my line manager (who is technical but not an excellent programmer): Sort stability. C++ says, here's sort function, and in the documentation by the way this is unstable, if you need a stable sort that's named stable_sort(); Rust says, here's a sort function, if you know enough to know you don't need a stable sort, there's an unstable_sort() function which is faster [and exists in tiny embedded systems since it doesn't need an allocator]. Unstable sort isn't unsafe (well, it is in C++ but that's C++ for you, it's not a fact about unstable sorting) but philosophically it violates the principle of least surprise as your default sort() function, and that would be a foot gun. Go has an "unsafe" library with the dangerous stuff in it. But unlike Rust it doesn't have the safe philosophy and so e.g. as we saw recently Go doesn't feel the need to even warn you that things aren't thread safe and some Go proponents think you're crazy if you expected anything to exhibit thread safety. If I saw a clear RPC philosophy in an OS like Windows I'd mostly go along with what you're saying. If when I looked at Windows I saw a bunch of loosely coupled systems communicating using a well defined protocol, I'm on board that's really not just a monolithic kernel. But what I see instead is mostly layers smeared on top of a monolithic kernel, some of which pretend to be RPC but are really just doing a syscall to some kernel code where the work happens. The language of RPC is used in some places, but the philosophy is largely absent.
ncmncm 4y ago
Judging by the quality of the Fuchsia code posted on HN recently, it looks like a complete dead end.
- CameronNemo 4y ago
  Yeah I have mixed feelings. I'm glad somebody is out there trying to make a ukernel work for real end user use cases. But until multiple vendors adopt and contribute to the project, it will never gain the momentum of Linux.
- pjmlp 4y ago
  It has worked out alright for Android, I bet you would assert the same.
yjftsjthsd-h 4y ago
> I wonder if the Linux kernel will take cues from these developments and start shoving auxiliary device drivers into userspace? So far, you can write drivers for USB devices (https://libusb.info/ https://libusb.info/), simple I/O devices (https://www.kernel.org/doc/html/v5.14/driver-api/uio-howto.html https://www.kernel.org/doc/html/v5.14/driver-api/uio-howto.h...), and filesystems (FUSE) in userspace. There are probably more, but those are the ones I know about off the top of my head.
- Matthias247 4y ago
  You can do also most of networking in userspace using XDP/AF-XDP (https://www.kernel.org/doc/html/latest/networking/af_xdp.html https://www.kernel.org/doc/html/latest/networking/af_xdp.htm...). The driver will only forward raw IP packets to userspace and everything else (like e.g. a TCP stack) resides there.
  - CameronNemo 4y ago
    Does that cause a ctx switch or any other overhead? What is the real world performance like relative to in-kernel networking?
    - Matthias247 4y ago
      It basically provides all packets in memory mapped space directly to userspace, and the NIC can populate that memory. There’s no context Switches involved unless you want them (eg wait for packets to arrive). The performance really depends on your application. There’s a lot in the kernel network stack (eg iptables/nftables) that not every application needs and that might be costly. But then again for usual TCP based applications with larger dataflows the kernel path is also already decently optimized with hardware offloads - and running userspace networking stacks comes with its own issues. If networking functions like sendmsg make up > 30% of an applications profile it can be worthwhile to investigate it.

ungamedplayer 4y ago

FUSE for filesystems already exists in userspace, so its not unheard of. Just making it work safely and secure is the first steps to having these kinds of features upstreamed.

SkyMarshal 4y ago

> Fuchsia/Zircon, Redox, and now this. Don't forget the original (for Linux anyway), SEL4. https://sel4.systems https://sel4.systems

senko 4y ago
seL4 has nothing to do with Linux, aside from the fact that the team was involved in another Linux-on-top-of-L4 project (L4Linux). Also, seL4 comes from a long line of L4 microkernels (https://en.wikipedia.org/wiki/L4_microkernel_family#History https://en.wikipedia.org/wiki/L4_microkernel_family#History) which actually predates Linux (L3 was developed back in '88).

survirtual 4y ago

You can already build auxiliary drivers / codecs / etc and insert them into modules, then put together a device tree overlay to use the module. With things like dt overlay fs, straight forward to insert new device trees. If you really wanted, could build a minimal kernel and move many devices to be inserted at runtime. Anyway, wouldn’t mind if all that was made a lot smarter and made more accessible to people.

blooalien 4y ago
Isn't that how Raspberry Pi does things?
- survirtual 4y ago
  It is.
kelnos 4y ago
That's not a microkernel architecture; that's a monolithic kernel with modules. (Just like Linux.)
- survirtual 4y ago
  I’m talking about linux responding to the comment about it.

Santosh83 4y ago

Linus is not a great believer in the microkernel architecture. Quite apart from that while certain things like FS can be shifted to userspace through FUSE, a ground-up rearchitecting into a microkernel may be extremely difficult for Linux at this stage. It would be more or less a rewrite of most of the core kernel I guess... and then the question of changes to the syscalls, which also Linus doesn't encourage.

jacquesm 4y ago
What Linus believes in or does not believe is hardly relevant though, what matters is what is the best solution going forward. Sunk costs are always smaller than the future costs.
CameronNemo 4y ago
Linus was not a believer something like 20 years ago. I wouldn't be surprised if his stance has significantly softened.
torginus 4y ago
Generally his skepticism was driven by 2 things around the time the microkernel debate happened: - Microkernels need more development effort for equal functionality, something that was a constraint when he was doing Linux on his own. - The context switching penalties on 386s were ginormous - it's much more reasonable now, I'd even say it's not much more penalizing than thread switching. - We live in a multi-master world with IOMMU - tons of devices have virtual address spaces on their own, with most of them doing DMA transfers.

pjmlp 4y ago

The monolithic kernel has lost, only the FOSS UNIX clones haven't yet catch up to it. OS X and Windows always had a hybrid architecture since the beginning, and with the push for user space drivers for third parties even more so. Most commercial RTOS are microkernel based, like QNX and INTEGRITY. Even Android imposes a fake microkernel like architecture since Project Treble, where since Android 8 classical Linux drivers are considered "legacy". Then there is the whole irony that those that strongly argue for monolithic kennels, nowadays run Linux on top of a type 1 hypervisor, full of containers.

tialaramex 4y ago
> OS X and Windows always had a hybrid architecture since the beginning "Hybrid architecture" is a PR exercise. These are monolithic designs with a better marketing team. Imagine if somebody tells you their new programming language has a "hybrid" numeric type. It has all the advantages of floating point numbers, yet none of the disadvantages of the integer types. Wow! Wait, hang on, let's look a bit more closely, those are floats. They've just described floats, but used some semantic sleight of hand to claim they're a "hybrid" numeric type.
- pjmlp 4y ago
  Some like to call it a PR exercise. Others enjoy that there is some effort in place to have RPC comunnication between kernel modules instead of direct function calls, a hard push for third party drivers only to exist in userspace and a standard ABI for extensions. I rather see the progress side, even if partial, than hold to legacy designs. See I could also call a PR exercise to safe languages that depend on using unsafe everywhere on their lower layers, maybe they aren't safe after all. And yet we know that isn't the case.
  - tialaramex 4y ago
    > See I could also call a PR exercise to safe languages that depend on using unsafe everywhere on their lower layers, maybe they aren't safe after all. Although it's easier to look at what's technically different in a language like Rust, probably more important is a philosophical difference and the resulting community. Let's use an example I gave recently to my line manager (who is technical but not an excellent programmer): Sort stability. C++ says, here's sort function, and in the documentation by the way this is unstable, if you need a stable sort that's named stable_sort(); Rust says, here's a sort function, if you know enough to know you don't need a stable sort, there's an unstable_sort() function which is faster [and exists in tiny embedded systems since it doesn't need an allocator]. Unstable sort isn't unsafe (well, it is in C++ but that's C++ for you, it's not a fact about unstable sorting) but philosophically it violates the principle of least surprise as your default sort() function, and that would be a foot gun. Go has an "unsafe" library with the dangerous stuff in it. But unlike Rust it doesn't have the safe philosophy and so e.g. as we saw recently Go doesn't feel the need to even warn you that things aren't thread safe and some Go proponents think you're crazy if you expected anything to exhibit thread safety. If I saw a clear RPC philosophy in an OS like Windows I'd mostly go along with what you're saying. If when I looked at Windows I saw a bunch of loosely coupled systems communicating using a well defined protocol, I'm on board that's really not just a monolithic kernel. But what I see instead is mostly layers smeared on top of a monolithic kernel, some of which pretend to be RPC but are really just doing a syscall to some kernel code where the work happens. The language of RPC is used in some places, but the philosophy is largely absent.

ncmncm 4y ago

Judging by the quality of the Fuchsia code posted on HN recently, it looks like a complete dead end.

CameronNemo 4y ago
Yeah I have mixed feelings. I'm glad somebody is out there trying to make a ukernel work for real end user use cases. But until multiple vendors adopt and contribute to the project, it will never gain the momentum of Linux.
pjmlp 4y ago
It has worked out alright for Android, I bet you would assert the same.

yjftsjthsd-h 4y ago

> I wonder if the Linux kernel will take cues from these developments and start shoving auxiliary device drivers into userspace? So far, you can write drivers for USB devices (https://libusb.info/ https://libusb.info/), simple I/O devices (https://www.kernel.org/doc/html/v5.14/driver-api/uio-howto.html https://www.kernel.org/doc/html/v5.14/driver-api/uio-howto.h...), and filesystems (FUSE) in userspace. There are probably more, but those are the ones I know about off the top of my head.

Matthias247 4y ago
You can do also most of networking in userspace using XDP/AF-XDP (https://www.kernel.org/doc/html/latest/networking/af_xdp.html https://www.kernel.org/doc/html/latest/networking/af_xdp.htm...). The driver will only forward raw IP packets to userspace and everything else (like e.g. a TCP stack) resides there.
- CameronNemo 4y ago
  Does that cause a ctx switch or any other overhead? What is the real world performance like relative to in-kernel networking?
  - Matthias247 4y ago
    It basically provides all packets in memory mapped space directly to userspace, and the NIC can populate that memory. There’s no context Switches involved unless you want them (eg wait for packets to arrive). The performance really depends on your application. There’s a lot in the kernel network stack (eg iptables/nftables) that not every application needs and that might be costly. But then again for usual TCP based applications with larger dataflows the kernel path is also already decently optimized with hardware offloads - and running userspace networking stacks comes with its own issues. If networking functions like sendmsg make up > 30% of an applications profile it can be worthwhile to investigate it.