Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS extensions are moving away from the kernel

eclecticlight.co

Post reply on HN
Print view View original

11–20 of 149 posts

Re: macOS extensions are moving away from the kernel

#11

Post by tomduncalf »

the_other wrote: post #7

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?

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 an OS/platform after all.

This does mean that some older gear which requires bespoke drivers and is no longer maintained will never work with new MacOS - one example that comes to mind is Allen and Heath’s Xone DB2 DJ mixer. Quite a lot of newer gear is USB class compliant, which means it doesn’t need specific drivers and so should be future proof.

Re: macOS extensions are moving away from the kernel

#12

Post by pjmlp »

cpach wrote: post #4
pjmlp wrote: 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.

Cool! Very interesting development given how bad reputation microkernels had for a while. (I’m thinking of Linux vs Minix/Hurd.)

Since Android 8, Linux is a kind of pseudo-microkernel, as all drivers are required to be Treble based, and traditional Linux drivers are considered legacy on the platform.

https://source.android.com/devices/architecture/hal-types

The Switch (yes the games console) uses a microkernel.

QNX an OS for human critical scenarios is a microkernel.

Finally, when arguing Linux vs Minix/Hurd, think of the irony of running Linux on top of a cloud hypervisor, with an endless load of Kubernetes or Docker loads.

Re: macOS extensions are moving away from the kernel

#13

Post by ace2358 »

tomduncalf wrote: post #11
the_other wrote: post #7

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?

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…

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 comes with it for controlling the mixer and saving patches and things so I’m not too enthused by it.

The new Bitwig 4 even dropped support for 10.13 which was a bit unexpected as it supports Windows 7.

Old gear getting dropped because of driver issues is really annoying, but I have come to terms with it. All music produces and studios deal with it. Some mixing rooms are on 20 year old hardware and that’s just how it is.

Re: macOS extensions are moving away from the kernel

#14

Post by solarkraft »

systemextensionsctl list yields 0 extensions on my system.

Are there any users of these extensions at this point?

It does seem a bit weird that installing these extensions supposedly doesn't require any user consent, even though stuff like screen recording or folder access does.

Re: macOS extensions are moving away from the kernel

#15

Post by jannes »

tagersenim wrote: post #10

Maybe not the point here, but what a beautiful way to style the website, with a drop-caps (the big initial letter, I had to look it up). It strikes a middle ground between the old-timey drop-caps and the 'new' web.

I read it on mobile and had no idea what you were talking about. The style seems to be absent on smaller viewport sizes.

Re: macOS extensions are moving away from the kernel

#16

Post by tomduncalf »

ace2358 wrote: post #13
tomduncalf wrote: post #11

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…

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!

Re: macOS extensions are moving away from the kernel

#17

Post by AshamedCaptain »

pjmlp wrote: post #3
nemothekid wrote: post #2

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?

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 modules (500MiB of them, according to the article) in the same address space.

Re: macOS extensions are moving away from the kernel

#18

Post by webmobdev »

nemothekid wrote: post #2

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?

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 it more like ios.

Re: macOS extensions are moving away from the kernel

#19

Post by AshamedCaptain »

nemothekid wrote: post #2

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?

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.

Re: macOS extensions are moving away from the kernel

#20

Post by pjmlp »

AshamedCaptain wrote: post #17
pjmlp wrote: 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…

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.

Post reply on HN