Live data from Hacker News

macOS extensions are moving away from the kernel

eclecticlight.co

91–100 of 149 posts

Re: macOS extensions are moving away from the kernel

#91
post #3

Earlier quoted context omitted.

The roadmap as presented by Apple at WWDC 2019 was that after an userspace replacement for a kernel subsystem gets presented, there is one year deprecation until it gets removed from the kernel on the following OS release. So there is one year to try out what might still be missing and give respective feedback. The long term roadmap is that macOS will eventually be much more microkernel like.

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…

How is removing 3rd party kernel modules a “pure political decision”. Do you really believe there are no technical/security factors behind this choice?

Re: macOS extensions are moving away from the kernel

#92
post #59

Earlier 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…

> The kernel is still going to be big and monolithic (it contains the entire BSD kernel in the same address space!) macOS does not use “the” BSD kernel (it’s not even obvious what your assertion even means since there are many members of the BSD family, each with their own kernel - none of which macOS uses).

Large parts of XNU come from both 4.3BSD and FreeBSD.

Re: macOS extensions are moving away from the kernel

#93
post #9

Earlier quoted context omitted.

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.

Aren't we making userspace/kernel space communication a lot more efficient with io-uring, though?

Likewise, eBPF allows userspace programs to perform some work inside kernel space to reduce syscalls.

I wonder if io-uring won't be a starting point for a "microkernelization" of Linux. It seems really effective as a message-passing interface.

Re: macOS extensions are moving away from the kernel

#94

This 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? I would have trusted literally anyone else to do a good job at this. Apple's in the business of brokering power though, I see no reason why they'd be motivated to make those APIs as rich as kexts.

Why?

Re: macOS extensions are moving away from the kernel

#95
post #3

Earlier quoted context omitted.

The roadmap as presented by Apple at WWDC 2019 was that after an userspace replacement for a kernel subsystem gets presented, there is one year deprecation until it gets removed from the kernel on the following OS release. So there is one year to try out what might still be missing and give respective feedback. The long term roadmap is that macOS will eventually be much more microkernel like.

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…

It's an engineering decision : buggy kernel extensions bring down the OS.

Re: macOS extensions are moving away from the kernel

#96

Is there any movement on providing the apis needed by osxfuse? Or just giving us fuse apis natively?

There's the File Provider API [1], but I don't think it's a proper replacement for osxfuse yet.

[1]: https://developer.apple.com/documentation/fileprovider

Re: macOS extensions are moving away from the kernel

#97

Earlier quoted context omitted.

"blessed" replacement Why did you use the word Blessed? I'm curious what made your brain choose that word instead of something neutral. Reminds me of "Walled garden" marketing speak instead of "Walled Prison". Edit- is there some sensitive nerve I hit?

I thought it might have been some kind of reference to the bless(8) command.

In context this is how it’s typically used.

Re: macOS extensions are moving away from the kernel

#98
post #13

Earlier quoted context omitted.

I’m running a PreSonus StudioLive 16.4.2 (1st gen) and am stuck on 10.13.6 because I’m pretty sure they didn’t release drivers for 10.14+. It’s a FireWire 400 device. I absolutely love it but because of it, I’m probably never going to upgrade my studio mac. I do wonder if it’s a class a compliant device and works without drives (I think I read somewhere that it might work) but I legitimately use the software that com…

> Old gear getting dropped because of driver issues is really annoying, but I have come to terms with it. Yeah, certainly on macOS. Not much you can do about it sadly!

[deleted]

Re: macOS extensions are moving away from the kernel

#99

I've love to hear what this means for realtime multi-channel audio applications. Would someone close to this give us a summary, or recommend some resources for the only-barely-knowledgeable?

Regarding audio, I currently use some tools from Rogue Amoeba called SoundSource, Loopback, and Audio Hijack that allow users to redirect, record, and add effects to virtual audio devices and applications on the system.

Currently, it's installed as a kernel extension, but I'm not sure if it will be possible for it to move to the new framework.

Re: macOS extensions are moving away from the kernel

#100

Earlier quoted context omitted.

I can’t comment on the internals of drivers etc as it’s not a domain I know much about, but I dabble with music production and can tell you that all my audio gear which requires drivers has been updated for Big Sur, which AFAIK is the new model. I’ve not noticed any change in performance at all, so I assume Apple have ensured the API covers the ground required for real time audio - it is one of their specialities as…

> it is one of their specialities as an OS/platform after all. Apple's been losing ground with creative-types across all industries and areas since their post-2000s peak: the major attitude-adjustment came with the reputational harm that came from the launch-and-downfall of the 2013 Mac Pro. As a wry zinger, I find it ironic that creative-types cannot express their creativity, and especially their individually by way…

And yet Mac sales have never been better: https://www.apple.com/newsroom/2021/04/apple-reports-second-...
Post reply on HN