The number of kernel extensions used by Apple is immense. I don't think they will be able to remove them from the OS anytime soon. Instead they will not support them and not sign them. Also, I would expect no further documentation so over time any use would be more difficult. But actually removing the kernel extension code would be a huge chore and there really isn't any reason to do so.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
(Theory) M1 Chipset simply not able to support PCIe via TB3 / TB3 Audio interfaces.
- Thread starter Hessel89
- Start date
- Sort by reaction score
I don't think it's that unfeasible.
I mean, I get what you are saying. The main reason why monolithic kernels have failed is because interfacing with third-party hardware was a mess — you either had to bake a monstrously fat kernel that supports everything under the sun, or you used slow interfaces that absolutely killed performance. So as long as Macs support heterogenous hardware, kernel extensions are a necessity.
But Apple Silicon? It's an integrated system with a very limited selection of hardware components. You can absolutely bake all the essential drivers into the kernel, without any drawbacks. And you can still let the user have low-level interface to their storage systems, drivers, webcams and even custom extension boards via user-space drivers: those will offer "good enough" performance for most cases. Looking at the information found so far by low-level hackers, I have a strong suspicion that Apple Silicon is designed with high-performance user-space drivers in mind: they have very fast interrupts, which should in theory allow low-overhead communication between the driver and the kernel API.
So yeah, I do believe that couple of years down the road we won't have any third-party kernel extensions at all. Sounds like a logical thing to do and a natural direction, with Apple deprecating the kext APIs left and right. But of course, I might be mistaken. Time will tell.
I don’t think there’s actually much disagreement between you and jdb8167 about the emphasized bit there. Apple has flat out said this is where things are going.
However, I do have to agree with jdb8167 that Apple isn’t likely to chuck the whole thing out, just block access to it. While Apple could link everything into a single binary, they already get a lot of the benefit of doing that with prelinked kernels. I disagree that Apple Silicon will homogenize the kernel driver pool all that much, either. The last couple of years of Intel stuff are already pretty homogenous.
Apple still needs to be able to revision the drivers for different generations of SoCs as technology evolves/changes, or they simply change what module designs they include on the SoC. So we’ll still see a proliferation of drivers required over time anyways. Apple is likely to need to do the same with the GPU as well, unless they want their work there to get stagnant. There’s benefit to continuing to bundle Apple-written chipset drivers that enable docks/etc to work without installing additional drivers, but those don’t need to be prelinked at all.
I
That's what I'm think as well honestly. But more the design vs the programing model. The SoC is very integrated and benefits from the design.
Last edited:
Don’t know who you are responding to but I said it is possible but not ready yet. They will probably drop it anyway in favour of Apple GPUs that they can have control and responsibility for.
One thing they can do immediately is open thunderbolt support for the Afterburner card.
Last edited:
Afterburner should already be working via Thunderbolt. The driver has been ported to ARM since the first Big Sur release.
If that was possible we would have seen some do it by now. Last I heard it’s pretty hard lock out.