We’re looking for a reliable way to determine whether an iPad device supports DriverKit. Since there doesn't appear to be a direct public API for this, our current approach is as follows:
-
Retrieve the device’s model identifier (e.g., "iPad14,8") and the iOS/iPadOS version.
-
Map the model identifier to a known iPad model and its associated chip. If the device has an M-series chip, we assume it supports DriverKit.
-
For future-proofing, we plan to assume that any future iPad with a model identifier of iPad15,* or higher will contain an M-series chip and therefore support DriverKit.
We have a couple of questions:
Is there a more reliable or official API to determine the chip version or DriverKit support?
Is it reasonable to rely on the assumptions outlined in steps 2 and 3 for determining DriverKit compatibility?
First off, please file a bug on this and the post the number back here. I have a suggestion below, but this really is something we should have proper API for, both to check for general support but also to provide better validation (for example, can a particular DEXT load on a particular system). It's also possible I've overlooked something (though I don't think so), but I'll confirm that once the bug is filed.
Is there a more reliable or official API to determine the chip version or DriverKit support?
Unfortunately, no, not really. I don't have a device at hande to test this against, but one thing you could try is seeing how IOKit behaves. In particular, I'd look at IORegistryGetRootEntry (both whether returns and entry and what you get from IORegistryEntryCreateCFProperties) as well as how IOServiceAddMatchingNotification behaves. I'm not sure you'll see any difference on unsupported devices, but if you get a clear divergence or failure, then that would be a reasonable check for support.
Is it reasonable to rely on the assumptions outlined in steps 2 and 3 for determining DriverKit compatibility?
Yes, with some qualifiers. The two obvious risks here are:
-
We ship a new device that doesn't support DriverKit.
-
We ship a new device that does support DriverKit, but uses a model format you're not prepared for.
The way to mitigate both of these is to think of this as an interface/user interaction issues, NOT a purely technical question. For the first case, that means making any DriverKit UI relatively non-intrusive so that the user isn't being bothered about functionality they can't use.
In the second case, I'd probably to either or both of:
-
Fail "open" by parsing use the expected/current format, but if that parse fails (because the format changed), then assume that device supports DriverKit.
-
Provide a UI path where the user can always "enable" your DriverKit support, even on device that you don't think support it.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
