My kext file should be loaded automatically at mac os boot time.
It currently appears in / Library / Extention, but it does not seem to be loaded automatically at boot time.
Is there a way?
For it to load automatically, it must either be an IOKit based kext, or another kext that gets loaded must depend on it.
If it's an IOKit kext, and there is no specific device which should trigger the loading of the kext, you can simply match the IOResources object. The official documentation on device & driver matching talks about how to set up matching in general, and about matching IOResources specifically.
Related
My NVMe driver works fine in macOS 10.15, but in macOS 11.0, it won't be loaded when the system boots up.
I knew my driver is installed to auxiliary kext collection.
when the macOS11 boot, the system always load applenvme driver in Boot Kernel Collection.
How to make the system load my kext instead of applenvme kext at startup?
Unfortunately, it is not possible to "win" IOKit matching against Apple's own kexts during early boot with macOS 11. The auxiliary collection is not considered for matching during that early phase, and by the time the system has progressed far enough to load auxiliary kexts, the Apple kext is already driving the device.
I recommend filing a bug with Apple about this behaviour.
I have a DriverKit extension that can match a usb audio device just fine, but if I leave the device plugged in during a reboot, the AppleUSBAudio kernel extension matches it instead.
Unplugging and replugging load my dext instead.
Is this to be expected? Do all System Extensions have this shortcoming? How can I remedy this?
On macOS 11, if one of Apple's kexts matches your device, and their driver is in the "boot" or "sys" collections (see man kmutil), which it normally will be, then their driver will win matching against yours, even if yours has a higher probe score.
On macOS 10.15, it should depend on whether or not their kext is in the prelinked kernel/kext cache. Third party kexts can also be included here so it's a little more democratic at least. Dexts can't be in the kextcache though.
I've filed an Apple DTS TSI about this issue and they've acknowledged it as a bug. I strongly recommend you file it as a bug as well to increase chances of it being fixed.
You should be able to work around it in a rather ugly way by explicitly force resetting the device from a user space daemon if your driver didn't manage to grab it. This will cause it to be re-enumerated by the USB subsystem, and for I/O Kit matching to be repeated, at which point your dext hopefully manages to win!
I am writing an OS X audio driver which will do some audio filtering. The driver kext is loaded on device connection and unloaded when device is unplugged. Driver configuration parameters are delivered via userspace application and can be changed during the device session.
If the helper app is closed then the driver will use the last received parameters (or fallback to default). However, instead of using default configuration every time the device is plugged in, it would be nice if the driver would load and store its configuration on kext load/unload respectively.
If I'm not mistaken, Windows uses registry for this type of thing. I found this message dating from year 2003, in which this sort of behavior is discouraged, and the only way to do it is to introduce a daemon which will launch on boot and will look after the kext.
Is there another (maybe easier) way to do the same thing 13 years later?
My Application wants to access a HID device I plugged in, but claiming the device does not
work because its already claimed by IOHIDDevice Driver.
In order to prevent that I learned, that I should create and install a codeless kext driver
for mac(OSX 10.8.2) to blackbox my device from beeing loaded.
I spent two days already and I did not have any success so far.
In my testcase you can find
Log from the USB prober
My codeless kext module
output from ioreg when my device is attached
It seems i cannot attach a file here.
please download it from http://www.guenther-sohler.net/testcase.tar.gz
Depending on what level of access you require, HIDAPI http://www.signal11.us/oss/hidapi/ may provide you with what you need. It's a library that uses IOHidManager as a backend on OSX. Works for me on OSX 10.7.5, no dummy driver required.
Check into a code less KEXT to declare your device as available to user space apps.
It is essentially a plist.
For Yosemite and Mavericks, it needs to be signed by an Apple Developer ID approved for KEXT - you need to be a Developer and apply for that.
I have created a codeless kext so that one of my USB devices does not get kidnapped by the AppleUSBUHCI driver. When I plug one in, it should be loading a different driver. It happens with both an FTDI and CSR device.
I put together my kext, and the info.plist looks a lot like the example here: http://www.projectosx.com/forum/index.php?showtopic=798 just with different VID/PID.
I ran kextutil with -entZ and the only warning was that I had a different CFBundleId for my personality. I followed the instructions here, Reading and writing to USB (HID) interrupt endpoints on Mac, to get it loaded.
When I loaded the kext, it said it loaded successfully, but I cannot see it with kextstat, and when I plug in my device it still gets hijacked. When I try to do a kextunload, it says the kext was not loaded.
Any help would be appreciated.
From the Apple lists, I learned that codeless kexts will not show up with kextstat unless they link to an existing driver. My personality that linked to the IOKit bundle would only show after load if it had stub code.
For my device, I found an existing driver for similar devices, and first injected a personality into that driver. I was able to verify it loaded when I plugged in my device, and I could open my device. I restored that driver to the original state. Then I created a codeless kext with the personality I had injected in to the existing driver. That driver then got loaded when I plugged in my device and I was then able to communicate with my device.
The solution to my original problem was the CFBundleIdentifier for my original codeless kext and the bcdDevice. From http://lists.apple.com/archives/usb/2009/Aug/msg00050.html, I got hints about different types of codeless kexts and realized I needed to use the CFBundleIdentifier for the existing driver.