101–110 of 199 posts
I wonder if there exists a parallel dimension where linux is microkernel design and folks are pushing for monolothic citing the driver friendliness and performance
Earlier quoted context omitted.
If parallel dimensions exist, then it's most certainly one of the closest dimensions to ours. If I'm sure of one thing, it's that as soon as we decided to build everything as Microkernels, we'd have the same squeaky wheels touting the massive benefits of Monotlithic OS design. We're hilariously cyclical in our preferences. "Think of all the runtime efficiencies of the shared memory, and how much easier it would be to…
The dirty secret is that we take a microkernel, rename the syscalls as "upcalls", throw in some hardware emulation code as a less efficient and uglier API for software that can't be bothered to be ported, and call it a hypervisor. Also, your phone's baseband processor almost certainly runs a microkernel, and likely so does your car.
> Microkernels are intended to create a minimal set of low-level operations that would be used to build an operating system. While it's popular to slap a monolithic kernel on top of your microkernel, this is not how microkernel based OSes are supposed to be; a real microkernel OS should have lots of separate pieces that used the microkernel services to work with each other. Using a microkernel as not much more than an overgrown MMU and task switching abstraction layer for someone's monolithic kernel is a cheap hack driven by the needs of academic research, not how they are supposed to be.
> By contrast, hypervisors virtualize and emulate hardware at various levels of abstraction. This involves providing some of the same things that microkernels do (eg memory isolation, scheduling), but people interact with hypervisors in very different ways than they interact with microkernels. Even with 'cooperative' hypervisors, where the guest OSes must be guest-aware and make explicit calls to the hypervisor, the guests are far more independent, self-contained, and isolated than they would be in a microkernel. With typical 'hardware emulating' hypervisors this is even more extremely so because much or all of the interaction with the hypervisor is indirect, done by manipulating emulated hardware and then having the hypervisor reverse engineer your manipulations. As a consequence, something like guest to guest communication delays are likely to be several orders of magnitude worse than IPC between processes in a microkernel.
People never seem to want to admit that sometimes, technology just dies, or at least becomes obscure, and so will invent bizarre "connections" between what we used to be working on and what we have now.
Earlier quoted context omitted.
Wow, that's a gish gallop if I've every seen one. But hey, it's lunch and why not. 1) Microkernels are defined by their small size > In summary, the microkernel provides mechanisms corresponding to hardware features. It doesn’t provide services, just fundamental mechanisms. In particular, it does not duplicate OS services. This misunderstanding was one of the causes for the failure of first-generation microkernels. T…
> 3) Microkernels are a diversion, because a userland server failure will be just as catastrophic as a kernel failure anyway Yeah, no. A kernel has access to all of the data on the machine. A compromised userland is much more strictly limited. Certainly if a compromised disk driver exposes a lot more data, not so much if you compromise your video driver. Compromising either in a monolithic kernel provides the same le…
> Certainly if a compromised disk driver exposes a lot more data, not so much if you compromise your video driver. Compromising either in a monolithic kernel provides the same level of access. Strong isolation boundaries strictly limit risk.
About the only part of the video drivers that runs in kernel space even on monolithic kernels these days are the drivers for the GPU's MMU. You screw that up and you're right back to where you started, corrupting random memory without regard for protection boundaries regardless of where that code lives. Everything else runs in user space, but not in an isolated process like on a ukernel, but directly in user process code, more like an exokernel.
> Driver support is always an issue. I don't see the problem.
My point underneath was comparing to other paravirtualized kernels was a best case comparison for ukernels, and zones/jails/containers has added a new more performant option for them that doesn't look as good for ukernels.
Earlier quoted context omitted.
The dirty secret is that we take a microkernel, rename the syscalls as "upcalls", throw in some hardware emulation code as a less efficient and uglier API for software that can't be bothered to be ported, and call it a hypervisor. Also, your phone's baseband processor almost certainly runs a microkernel, and likely so does your car.
Any recent iPhone/iPad, Apple Watch, the iMac Pro, and Macbook Pro touch bar, all contain Apple's "Secure Enclave", which runs the L4 microkernel: > The Secure Enclave runs an Apple-customized version of the L4 microkernel. This microkernel is signed by Apple, verified as part of the iOS secure boot chain, and updated through a personalized software update process. https://www.apple.com/business/docs/iOS_Security_Gui…
Earlier quoted context omitted.
The dirty secret is that we take a microkernel, rename the syscalls as "upcalls", throw in some hardware emulation code as a less efficient and uglier API for software that can't be bothered to be ported, and call it a hypervisor. Also, your phone's baseband processor almost certainly runs a microkernel, and likely so does your car.
https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMi... > Microkernels are intended to create a minimal set of low-level operations that would be used to build an operating system. While it's popular to slap a monolithic kernel on top of your microkernel, this is not how microkernel based OSes are supposed to be; a real microkernel OS should have lots of separate pieces that used the microkernel services to w…
https://microkerneldude.wordpress.com/2008/04/03/microkernel...
NOVA is an open-source micro-hypervisor available in GenodeOS that similarly combines hypervisor functionality with a microkernel-like design:
The Xen hypervisor also got many of its design elements from the Nemesis OS, which had a lightweight kernel. There's plenty of overlap possible. A number of research and production systems are also both hypervisors and microkernel-like, too. So, it's more an existing concept than a bizarre, hypothetical connection. For OKL4, also deployed in over a billion phones they claim.
Earlier quoted context omitted.
And what many seem to be unaware, is that project Treble made Android Linux into a microkernel where drivers use Android IPC to talk with the kernel. https://source.android.com/devices/architecture/kernel/modul... https://source.android.com/devices/architecture/hidl/ So everyone running Android Oreo or newer on their phones, not only has a microkernel on their basebase radio, they also have a Linux tamed into a micro…
I don't see a microkernel architecture here. Requiring drivers to be loadable modules is just arriving in the 1990s of monolithic kernels. Also, only new devices with SoCs introduced for Android 9 are required to use kernel modules and kernels newer than 3.18. [1] This means most (updated) Android 8 devices in the field are not Project Treble and are running old-style module-less kernels and don't have A/B system par…
There are two HALs in Android.
The old HAL, previous to Treble, which was hardly used by OEMs.
And the new HAL, which is enforced by Treble.
On the new HAL, drivers are implemented as Android services using Android IPC via interfaces defined in HIDL, or by using the new shared memory APIs introduced in Oreo as well.
https://source.android.com/devices/architecture/hidl/service...
https://source.android.com/devices/architecture/hidl/binder-...
https://source.android.com/devices/architecture/hidl/memoryb...
https://source.android.com/devices/architecture/configstore/
Still waiting for GNU hurd.
Earlier quoted context omitted.
Lack of performance on microkernels is a myth nowadays. QNX and many embedded OS, some of which driving high integrity software, are all microkernel based. Including the one most likely handling the real time communication of this mobile radio.
It's not a myth. Real time doesn't mean fast, it just means deterministic. And I'll throw out there that many times the the term microkernel in a lot of embedded OSs has been contorted by marketing speak into something unrecognizable. Basically if you have multiple threads in the kernel, structure the kernel code into modules (but perhaps don't even allow dynamic loading of modules), and can communicate through async…
https://www.youtube.com/watch?v=PYZDl4RNEVE
Maybe they had some stuff in kernel mode in there. They still show you can start with a microkernel as the baseline then optimize from there retaining the architecture with its benefits in average case or most cases.
The Jury Is In: Microkernel OS Design Is Flawed. See I can make clickbait titled papers also.
Still waiting for GNU hurd.