The initial announcement from WWDC 2019.
macOS extensions are moving away from the kernel
21–30 of 149 posts
Re: macOS extensions are moving away from the kernel
#22Earlier quoted context omitted.
I am quite sure that we have been other this several times in HN. The fact that they're no longer going to allow loading of 3rd party kernel modules (a pure political decision) does not a make a microkernel (which is an architectural style). The kernel is still going to be big and monolithic (it contains the entire BSD kernel in the same address space!), and they're still going to be loading Apple-authorized kernel m…
As you wish, I am no longer going to debate the pedantic meaning of pure microkernel ideology. I rather be happy for the improvements in the long term roadmap and overall outcome for the eco-system.
"Pedantic"?
If you just consider disallowing 3rd party modules to be a "microkernel" all while the kernel itself still loads most if not all (approved) drivers such as PCI bus, storage devices or filesystems in the same address space, then _all_ current major operating systems are "microkernels".
Re: macOS extensions are moving away from the kernel
#23This article does a good job of explaining how kernel extensions worked under Intel and how they will work under M1, and the blessed replacement for kernel extensions by Apple under M1. What it's missing, and what I assume everyone's questions is: Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions?
> Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions? From what I remember reading from some macOS Application Firewall makers, no. (And that's ofcourse, intentional.) While it is true that poorly coded Kernel extensions can make an OS unstable, this is just another example of Apple taking away more control from its users and further crippling macOS to make…
After feedback from aforementioned firewall developers, changes were made to network extensions that allowed them to do what they wanted with their applications (for the most part, at least).
I still think that it’s a worse in-practice system than kexts but they are responding to feedback at least.
You can still load kernel extensions in Big Sur by disabling SIP, though.
Re: macOS extensions are moving away from the kernel
#24Earlier quoted context omitted.
FYI, Linux userspace drivers were introduced in 2006-2007 and improved multiple times over the years. Some of my filesystem & networking drivers run in usersapce. The monolithic vs microkernel debate was pretty clueless at times. Core Linux is smaller than dito hurd when configured with similar functionality. OSX mach has always been a hybrid kernel. In a sense Linux is too but you can also configure it as a mostly-m…
Some of the userspace drivers are even shared between OSX and Linux, via FUSE.
Another example would be userspace network drivers that directly talk to the network card. Those tend to be much more performant than using the kernel driver due to avoiding the need to context switch from userspace to kernelspace.
Re: macOS extensions are moving away from the kernel
#25This article does a good job of explaining how kernel extensions worked under Intel and how they will work under M1, and the blessed replacement for kernel extensions by Apple under M1. What it's missing, and what I assume everyone's questions is: Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions?
The entire "ring 1" thing is highly likely false. It's been decades since I last saw anyone using the x86 ring levels and I seriously doubt XNU is using them. In any case, extensions run in the same address space as the rest of the kernel making any such "rings" pointless.
Rings 1 and 2 don't even exist on AMD64/x86-64.
Re: macOS extensions are moving away from the kernel
#26Earlier quoted context omitted.
I am quite sure that we have been other this several times in HN. The fact that they're no longer going to allow loading of 3rd party kernel modules (a pure political decision) does not a make a microkernel (which is an architectural style). The kernel is still going to be big and monolithic (it contains the entire BSD kernel in the same address space!), and they're still going to be loading Apple-authorized kernel m…
As you wish, I am no longer going to debate the pedantic meaning of pure microkernel ideology. I rather be happy for the improvements in the long term roadmap and overall outcome for the eco-system.
It’s not about pedantry; whatever rules you define for a micro kernel it shouldn’t be rules for thee but not for me
Re: macOS extensions are moving away from the kernel
#27This article does a good job of explaining how kernel extensions worked under Intel and how they will work under M1, and the blessed replacement for kernel extensions by Apple under M1. What it's missing, and what I assume everyone's questions is: Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions?
The entire "ring 1" thing is highly likely false. It's been decades since I last saw anyone using the x86 ring levels and I seriously doubt XNU is using them. In any case, extensions run in the same address space as the rest of the kernel making any such "rings" pointless.
I mean, recent developments in the Windows/NT architecture uses virtualization to create a three-level "ring" system, so while it's not strictly architectural "rings", it's effectively a tri-ring system.
But then, I haven't delved into how macOS in M1 precisely works.
Re: macOS extensions are moving away from the kernel
#28Earlier quoted context omitted.
The entire "ring 1" thing is highly likely false. It's been decades since I last saw anyone using the x86 ring levels and I seriously doubt XNU is using them. In any case, extensions run in the same address space as the rest of the kernel making any such "rings" pointless.
I mean, recent developments in the Windows/NT architecture uses virtualization to create a three-level "ring" system, so while it's not strictly architectural "rings", it's effectively a tri-ring system. But then, I haven't delved into how macOS in M1 precisely works.
Virtualization is indeed the last user of the x86-ring 1 that I remember. But it is much easier to put an entire virtualized kernel in a different ring (x86 or ?) than selectively put pieces and parts of one in different rings, which no one does.
Re: macOS extensions are moving away from the kernel
#29Is there any movement on providing the apis needed by osxfuse? Or just giving us fuse apis natively?
Re: macOS extensions are moving away from the kernel
#30Earlier quoted context omitted.
I mean, recent developments in the Windows/NT architecture uses virtualization to create a three-level "ring" system, so while it's not strictly architectural "rings", it's effectively a tri-ring system. But then, I haven't delved into how macOS in M1 precisely works.
Virtualization is indeed the last user of the x86-ring 1 that I remember. But it is much easier to put an entire virtualized kernel in a different ring (x86 or ?) than selectively put pieces and parts of one in different rings, which no one does.
> Virtualization is indeed the last user of the x86-ring 1 that I remember.
Yes, I know, but I'm referring to hardware virtualization, essentially making "ring -1" "ring 0" and "ring 0" "ring 1".