Interesting.<p>The company I worked for and our competitor VMWare both had to create small kexts to enable on-the-fly capture of USB devices. We both accessed USB devices from user-space, but we needed to put small kexts in the kernel to prevent class drivers from being automatically attached to general USB devices. There was really no race-free user-space way of doing this and Apple ignored our messages on their dev forums when we asked for assistance.<p>I wonder if they’ve added an interface for this? Or maybe promiscuous USB device control just isn’t going to be possible now?
I wonder if this is the end of drivers for 3rd party PCIe/thunderbolt high performance NICs? I imagine that this may make Macs less viable for situations where having a reasonably high performance 3rd party NIC is important (eg, video editing).<p>Are there any details about DriverKit that are available?<p>I used to be a Mac driver developer ~10 years ago or so. I did one of the first 10G drivers for Macos, and MacOS performance was always terrible compared to Linux or BSD, but I can't imagine that moving it into userspace is going to help anything. MacOS boundary crossing (eg, syscall, ioctl, and Mach traps) performed even worse than their network stack as compared to Linux/BSD.
If you want to know how much non-Apple kernel extensions you use, use "kextstat" and filter out com.apple. In my case, I only use Karabiner:<p><pre><code> % kextstat | grep -v com.apple
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
185 0 0xffffff7f84cc0000 0x5000 0x5000 org.pqrs.driver.Karabiner.VirtualHIDDevice.v061000 (6.10.0) 4D004D1A-ED2F-3780-AD53-A10F286EC759 <51 6 5 3 1>
%</code></pre>
> Kernel programming interfaces (KPIs) will be deprecated as alternatives become available, and future OS releases will no longer load kernel extensions that use deprecated KPIs by default.<p>This is the key part, as presented during the WWDC 2019 talks, the long term roadmap is to make macOS into a proper mikro-kernel OS.<p>This is just the start.
Here's a text transcript from the WWDC 2019 session that gave an overview.<p>>A System Extension is part of your app that extends the functionality of the operating system in ways similar to a Kernel Extension but running in user space outside the kernel.<p><a href="https://asciiwwdc.com/2019/sessions/702" rel="nofollow">https://asciiwwdc.com/2019/sessions/702</a>
Kernel extensions being deprecated is not news (it was announced at WWDC). The only real new info in this post is that 10.15.4 will pop up warning dialogs when loading the certain types of kexts that have replacement APIs available.
Curious if anyone knows what Dropbox will do about SmartSync. KAuth extensions are likely out as of 10.16, and the Endpoint Security extensions don’t let you block a reply for more than 60 seconds, so you can’t dynamically page in large files anymore.
Is this the end of any form of fuse style fs on macOS? (whether osxfuse, or an open source fork of an earlier version of it)<p>They say that future OS releases will no longer load deprecated KPIs, but they do not note the VFS KPIs as deprecated in their list.
Just looked through my kexts. I've got two that I use, one that I dont, all signed and approved by Apple:<p>* Driver for RTL815X that works with my USB Ethernet adapter from RTL.<p>The standard Apple driver refused to run at 1G, only at 100Mb. It'll be interesting to see if they update the drivers any time soon.<p>* Tripmode that controls network I/O (I don't use it)<p>* Karabiner Elements to handle my custom keyboard<p>I use the (excellent) Karbiner-Elements to handle my keyboard and it has a kext that sets up a virtual keyboard and virtual pointer as HID devices. So I'm guessing that's going to need to be converted from a kext to something using the HIDDriverKit.
As usually, Apple does not give developers any time to react. There is no migration plan save for one video from WWDC where they briefly describe some alternatives.<p>> In macOS 10.15.4, use of deprecated KPIs triggers a notification to the user that the software includes a deprecated API and asks the user to contact the developer for alternatives.
I really hope that this is the final nail in the coffin for third party Anti Virus vendors.<p>It's been really worrying to see large enterprises that have moved from Windows to macOS and carry their thinking that the need to install a third party AV product (which in turn often acts as a near-unrestricted way into the kernel).
This is yet another reason to move away from MacOS. The blocking of 32-bit apps, a requirement to have Apple notarize every application, and now the removal of kexts.<p>If Apple still made great software and even better hardware then I wouldn't care, but that hasn't been the case for years.
> <i>At WWDC19, we announced the deprecation of kernel extensions</i><p>The title as written deserves a (2019) since they announced this to developers last year.
I wonder about drivers for PCIe add-in cards for the new Mac Pro. I have a client that has asked me to develop such a driver for their card so they can run on modern Mac Pro systems. I’d work entirely in userland via DriverKit if I could, but I don’t think the necessary APIs to interact with PCIe hardware are available.
>IOUSBFamily has been deprecated and headers removed from SDK since macOS El Capitan (10.11). All clients should move to IOUSBHostFamily or USBDriverKit, where appropriate and outlined below.<p>lol which one of you? i fully sympathize but oof, guess you lost that fight
As a total layman to developing kernel extensions, is this another example of apple limiting what you can do with their hardware, or just an effort to get developers to modernize how they make drivers for macOS?
How will hackintoshing work without kexts? I'm no expert but have built a few, and they make extensive use of them to make non-apple hardware work properly and to add functionality.
It's shit like this that drives me never to use Apple products. Oh, your company gives Apple laptops to SWEs and I can't order something different? No, I won't work with you. I need full control over the machine I spend my day driving, and this control includes loading kernel modules on my own damned computer if i want to do that.
This was my favorite kennel extension. It allowed for accessing memory via a device that you could call `cat` on, grep etc. <a href="https://www.osxbook.com/book/bonus/chapter8/kma/" rel="nofollow">https://www.osxbook.com/book/bonus/chapter8/kma/</a>
Right now I use an empty kext to prevent macOS from seizing control of a hardware programmer (keeping it from being accessed by the program that uses it). It was a hack of a solution, but it worked.<p>This means for the moment, I don't have an upgrade path that works for me...
I need Kernel Extensions for Karabiner and USB-to-TTY drivers to talk to and program firmware on embedded boards. If I can no longer do this, my next machine is not a Macbook. Unless there is a different way, this is a dealbreaker.
Could this be the beginning of the arm transition?<p>I mean porting kernel extensions would probably be a big deal, so deprecating them would be the first step.
I'd just like to point out that the title is a bit misleading -- They are deprecating extensions that use parts of the kernel API that have alternatives, as these become available.<p>How well that will work in practice remains to be seen. But they aren't simply deprecating all kernel extensions.
Huh. The only non-Apple ones on my Mac are for:<p>* VMWare Fusion
* Little Snitch
* Dropbox<p>plus one for a firewall I don't run anymore and could get rid of.
I just found Turbo Boost Switcher, which uses a kernel extension to manage intel turbo boosting. I'm a little worried that this sort of change will prevent this kind of innovative work (and quite possibly the application altogether. <a href="http://tbswitcher.rugarciap.com/" rel="nofollow">http://tbswitcher.rugarciap.com/</a>