Building SimpleAudioDriver example

look in ~/Library/Developer/Xcode/UserData/Provisioning Profiles for the Xcode-generated profile. You can use QuickLook to inspect the profile. If you added the DriverKit USB (development) Capability, your profile should have idVendor='*'. This wildcard value will only work for development builds.

Your entitlements.plist should have an entry called com.apple.developer.driverkit.transport.usb or "DriverKit USB Transport' which is an array, containing one or more items, each of which is a dictionary. Each dictionary should have an item with key idVendor and value a decimal number equal to the vendor ID of the device you're driving.

Can anyone give advice? Thanks a ton!

Unfortunately, this is actually the first time I've looked at "Building an Audio Server Plug-in and Driver Extension" and, to be honest, that is not great sample code. Using darwinup in a shell script is not something any one should actually "do". I've already filed a bug on this (r.163226098), but you're going to need to do a bit of work to end up with something "reasonable".

SO, what I would actually suggest is the following:

1. Start with the sample "Communicating between a DriverKit extension and a client app" and get it building and running. That's our simplest sample and will let you sort out the basic build and install process.

2. Once that's working, replace the DEXT inside that sample with the DEXT from "Building an Audio Server Plug-in and Driver Extension".

Once that's done, you'll have an installer app with an embedded DEXT, which is what ALL DEXT need to be shipped as anyway.

Shifting to the codesign front:

I would be ok for now with the local option, but XCode 16.4 doesn't show the option "build to run locally" (SIP is disabled).

The old "disable SIP" process is no longer necessary. The "modern" approach uses the "Development Only" entitlement variants, which allow your DEXT to match against "any" hardware, but can ONLY be used in Development builds. Those use this configuration described above:

If you added the DriverKit USB (development) Capability, your profile should have idVendor='*'. This wildcard value will only work for development builds.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for the information.

The Communicating example says in the readme to disable SIP, so which one is right?

Building the Communicating example yields the same error, saying "file a bug report" like in the screenshot above.

And the provisioning profile is missing the "driverkit.allow-any-userclient-access" entitlement.

How should I add that? I cannot see that in the checkboxes below the error.

Thanks in advance

The Communicating example says in the readme to disable SIP, so which one is right?

Technically, we're both right as the old "disable SIP" flow does still work (at least theoretically). However, the new flow is so much easier that I wouldn't bother with the SIP flow.

And the provisioning profile is missing the "driverkit.allow-any-userclient-access" entitlement. How should I add that?

Don't bother, just delete it from your Entitlement.plist. This forum thread outlines exactly how the user client entitlements work and, with that context, what you'll actually end up doing is:

1. In the long run, you'll eventually request the "right" user client entitlements based on your needs, using the forum post above to figure out which one is right for you.

2. In the short run, you can sidestep the entire problem. Your DEXT will already allow connections from code that's signed by your team and your app can get past its restrictions by either disabling the app sandbox and/or adding the "IOKit User Client Class Temporary Exception". See this forum post for a detailed rundown of that as well as some additional guidance.

Building the Communicating example yields the same error, saying "file a bug report" like in the screenshot above.

Deleting "com.apple.developer.driverkit.userclient-access" should clear this issue. Quoting myself on this particular Xcode error (r.163506095):

"One thing to be aware of here is that Xcode has a "bias" in the way it presents codesign errors where it assumes the Entitlement.plist is "correct" and the profile is "wrong". However, in practice that's basically "never" the case with DriverKit entitlements and tends to lead to a lot of "flailing" trying to somehow "fix" the provisioning profile. This error ALWAYS means that "the entitlement.plist doesn't match the profile". You fix that by:..."

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Empty post

Hi Kevin,

Deleting "com.apple.developer.driverkit.userclient-access" should clear this issue.

Thank you, that helped indeed the compilation to succeed. The connection fails though:

The log shows:

sysex didFailWithError: extension category returned error

I was wondering now, if I should try to fix the Driver Communication example or straight move on to adapt the SimpleAudioDriver example.

Unfortunately I don't know where to start. I am a C++ developer by trade and the os specific toolchains are hard to grasp for me.

Thank you for all the help so far!

Daniel

Thank you, that helped indeed in the compilation to succeed. The connection fails though: The log shows: sysex didFailWithError: extension category returned error

OK, so that's an install error, not an IOKit issue. Have you configured everything to be signed by the same team? What, if anything, is being printed in the system log?

Also, keep in mind that you DO need to add the “com.apple.security.temporary-exception.iokit-user-client-class” entitlement to your app (NOT the DEXT), as described in this forum post.

I was wondering now, if I should try to fix the Driver Communication example or straight move on to adapt the SimpleAudioDriver example.

That's ultimately up to you, but I would stick with the Driver Communication example and get it working first. One of the lessons I've learned over and over again is that it's MUCH easier to "expand" on something that works vs. making something work from "scratch". This is basically our simplest sample, so I think your best bet is to get it working first.

Unfortunately I don't know where to start. I am a C++ developer by trade and the os specific toolchains are hard to grasp for me.

Welcome to the party... So, a few general pointers and warnings here:

(1)
DriverKit is not well documented and, to be blunt, fairly "weird". It's basically written using the C++ variant IOKit uses (which is straightforward), with a number of complex macros layered on top of it. The result of all that is not always as readable as it could be.

(2).
Using and understanding DriverKit basically requires understanding IOKit, something our documentation never actually says. The good news here is that IOKit actually does have fairly good "foundational" documentation in the documentation archive. Here are a few of the documents I'd take a look at:

• IOKit Fundamentals

• IOKit Device Driver Design Guidelines

• Accessing Hardware From Applications

• Special mention to QA1075: "Making sense of IOKit error codes", which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review).

__
Kevin Elliott
DTS Engineering, CoreOS/Hardware