User Profile

My NetworkingDriverKit extension is failing on Monterey. The RegisterEthernetInterface() call is returning a result of 0x08e4bd01. This code works correctly on both Catalina and BigSur. Can't find any information on that error code. Or what might have changed for Monterey. Suggestions would be welcome! networkInit_Impl [result = RegisterEthernetInterface(ivars->fHostMAC, ivars->poolPacketBuffer, ivars->queues, 4)] Unkown_kIOReturn 8e4bd01

I am using #include <atomic> in my DriverKit extension c++ file. This compiled correctly with older versions of Xcode, but starting with Xcode 12.5 (and beta 13) the compiler can no longer find some required types. For example: In file included from /Applications/Xcode-12.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/atomic:571: In file included from /Applications/Xcode-12.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__threading_support:14: In file included from /Applications/Xcode-12.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/chrono:827: /Applications/Xcode-12.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ctime:57:9: error: no member named 'clock_t' in the global namespace; did you mean 'clockid_t'? using ::clock_t; There are various other missing definitions, time_t, tm, clock, difftime, time, asctime, ctime, gmtime, localtime and strtime, none of which I am trying to use. I assume that there was a change in the default include paths, but can't see what it is. Suggestions would be welcome! Thanks!

Are there any examples showing USB I/O using DriverKit apis?

Is there a correct method for replacing an older version of a DriverKit extension? Specifically, will the Installation application need to be able to detect if the older DEXT is installed and activated and specifically be able to deactivate it before trying to install a new version?

With the current version of Big Sug (Intel and Apple Silicon), our previously working DriverKit Extension now fails when we plug in our USB test device. Any suggestions would be welcome. This is with freshly built and notarized app bundles and with a previously built and notarized bundle that was tested to work correctly with the previous version of Big Sur. The installation application can successfully activate the bundle. -- com.apple.system_extension.driver_extension enabled active teamID bundleID (version) name [state]F7XQY5N68B com.belcarra.logitech-driverkit (0.1.1/0.1.1) com.belcarra.logitech-driverkit [activated waiting for user] We see this error in the system log when the DextLaunch() call fails. Received kext load notification: com.apple.driver.usb.cdc kernelmanagerd[97:2578] Error occurred while handling request "DextLaunch(arguments: Optional(["Driver Extension Server Tag": 4294969558, "CFBundleIdentifier": com.belcarra.belcarra-driverkit-bigsur, "Driver Extension Server Name": com.belcarra.driverkit.musblan, "Check In Token": 22331]))": Invalid argument: Can only launch dexts from a verified SIP protected path If I reboot and disable SIP, everything works correctly. Feedback: FB8963751

Will it be possible to distribute a DriverKit Installation Application via the Mac App Store?

After updating to the new Xcode 12 ( not beta) building our driver kit extension fails for the derived source file Comm.iig.cpp with messages complaining about too many arguments to IODataQueueDispatchSource. This is from Big Sur running on Intel, I am seeing the same behaviour on Catalina. This worked correctly with the previous version of Xcode and the previous Xcode-beta. Users/sl/work20/musbland/comm-dext/build/driverkit.build/Debug-driverkit/DriverKit.build/DerivedSources/com.belcarra.belcarra-comm-driverkit/Comm.iig.cpp:296:186: error: too many arguments to function call, expected 3, have 4 ret = IODataQueueDispatchSource::DataAvailableInvoke(rpc, self, SimpleMemberFunctionCast(IODataQueueDispatchSource::DataAvailableHandler, *self, &Comm::TxAvailableImpl), OSTypeID(OSActionComm_TxAvailable)); In file included from /Users/sl/work20/musbland/comm-dext/build/driverkit.build/Debug-driverkit/DriverKit.build/DerivedSources/com.belcarra.belcarra-comm-driverkit/Comm.iig.cpp:9: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/DriverKit19.0.sdk/System/DriverKit/System/Library/Frameworks/DriverKit.framework/Headers/DriverKit.h:44: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/DriverKit19.0.sdk/System/DriverKit/System/Library/Frameworks/DriverKit.framework/Headers/OSCollections.h:33: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/DriverKit19.0.sdk/System/DriverKit/System/Library/Frameworks/DriverKit.framework/Headers/OSCollection.h:35: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/DriverKit19.0.sdk/System/DriverKit/System/Library/Frameworks/DriverKit.framework/Headers/OSObject.h:46: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/DriverKit19.0.sdk/System/DriverKit/System/Library/Frameworks/DriverKit.framework/Headers/OSMetaClass.h:185:28: note: expanded from macro 'OSTypeID' #define OSTypeID(type) g type ## MetaClass ^~~~~~

Can someone provide a short example of how to use the QUEUENAME macro in the iig file? For an IOUserNetworkTxSubmissionQueue, it appears to be necessary to do an IODispatchQueue::Create("name", &amp;IODispatchQueue queue) and then do a SetDispatchQueue("queue_name", queue). The documentation for IOService::SetDispatchQueue() says The name to assign to the queue. Use this name with the QUEUENAME macro to designate where you want the methods of your class to execute. Include that macro at the end of your method signature methods in the .iig file of your class.

Catalina (and Big Sur) have a kext AppleUSBECM.kext and driver extensions AppleUSERECM.dext and AppleUSERECMData.dext. Plugging an ECM device in it appears that the kext is being used preferentially. How can the system be configured to use the ECM Driver Extensions instead.

What is the replacement for IOService::serviceMatching() in DriverKit?Or an alternate method for one instance of a Driver Extension to get access to another? I'm implementing for a multiple interface USB device and following the design pattern in the AppleUSBCDC examples to allow access between extensions for each to the USB Interfaces. E.g. CDC ECM style with COMM and DATA.