DriverKit CppUserClient Searching for dext service but Failed opening service with error: 0xe00002c7

0xe00002c7 is kIOReturnNotSupported (from IOReturn.h). You're trying to open four objects, none of which support that operation.

I have had more success using IOServiceNameMatching, and giving the driver a unique name (call SetName in your dext, before RegisterService). This way you should make only one attempt to open your driver through its user client.

Also, make sure you actually implement NewUserClient_Impl in your dext.

Thanks, Smith,

Thanks for your quick response. There are so few resource about DriverKit developing that I can find. So, thank you very much!

I follow your suggestion, add the code for NewUserClient

kern_return_t IMPL(testinfo, NewUserClient)
{
    kern_return_t ret = kIOReturnSuccess;
    IOService* client = nullptr;
    
    Log("fredapp NewUserClient()");
    
    ret = Create(this, "UserClientProperties", &client);
    if (ret != kIOReturnSuccess)
    {
        Log("fredapp NewUserClient() - Failed to create UserClientProperties with error: 0x%08x.", ret);
        goto Exit;
    }
    
    *userClient = OSDynamicCast(IOUserClient, client);
    if (*userClient == NULL)
    {
        Log("fredapp NewUserClient() - Failed to cast new client.");
        client->release();
        ret = kIOReturnError;
        goto Exit;
    }
    
    Log("fredapp NewUserClient() - Finished.");
    
Exit:
    return ret;
}

And change the CppUserClient

ret = IOServiceGetMatchingServices(kIOMasterPortDefault, IOServiceNameMatching(dextIdentifier), &iterator);

But still got the message: Failed to match to device.

By the way, in CppUserClient.cpp

ret = IOServiceOpen(service, mach_task_self_, kIOHIDServerConnectType, &connection);

our dext is using the PCIDriverKit.framework, and include the headers

#include <DriverKit/IOUserServer.h>
#include <DriverKit/IOLib.h>
#include <PCIDriverKit/PCIDriverKit.h>
#include <DriverKit/IODMACommand.h>
#include <DriverKit/IODispatchSource.h>
#include <DriverKit/IOTimerDispatchSource.h>
#include <DriverKit/IOInterruptDispatchSource.h>

So I try to replace the kIOHIDServerConnectType to kIOPCIDeviceConnectType, but I do not know how to import the correct header file. I try to include

#include <IOKit/PCIDriverKit.h>

but Xcode report file not found.

What's the next step to try?

And I find a Github repository SamsungDS/MacVFN, in the file MacVFN/MacVFNUserClient.cpp,

#include <DriverKit/IOUserServer.h>
#include <DriverKit/IOLib.h>
#include <DriverKit/OSData.h>
#include <DriverKit/OSDictionary.h>
#include <DriverKit/OSNumber.h>
#include <PCIDriverKit/PCIDriverKit.h>

If it is workable (because I was failed to include PCIDriverKit/PCIDriverKit.h), and I will try to download and inspect the code to find some information and try to figure out how to fix my problem.

Best Regards, Charles

The value kIOPCIDeviceConnectType is just a number, the third parameter to IOServiceOpen called by your user-space client code. That number appears as the first parameter to NewUserClient_Impl in your dext. If your dext is your own, you can use any value you like, or ignore it entirely.

If your code is no longer reporting the kIOReturnUnsupported error, but instead printing only "Failed to match to device", that suggests that there's no driver with the correct name installed. Did you call SetName("com.accusys.scsiDriver"); within your dext's Start_Impl()?

I've never written a PCI driver, sorry can't help you with that.

Don't say that, Smith. Valuable information about dext is almost impossible to find online, so any help you provide is incredibly significant to me. I'm truly grateful.

This is my first time working on dext development, I always ask Copilot or ChatGPT for help, but their answers are mostly non-functional code, which is truly frustrating.

For example, when I try to connect to this dext, their user space client code is not workable also.

May I politely ask if you have a basic and functional Xcode project for both the dext and client sides that I could use as a reference?

Let me start by jumping back to here:

We try to use the CppUserClient.cpp to communicate with the dext, but can not get the dext service. The debug message as below:

Failed opening service with error: 0xe00002c7.

I posted some IORegistry matching code in this post, but the code I actually want to you to grab is my "KE_PrintIOObject" function:

void KE_PrintIOObject(io_service_t myObj)
{
    if(myObj != 0)
    {
        NSString* className = CFBridgingRelease(IOObjectCopyClass(myObj));
        NSLog(@"Class Name = %@", className);
        CFMutableDictionaryRef propDictionary = NULL;
        if(IORegistryEntryCreateCFProperties(myObj, &propDictionary, CFAllocatorGetDefault(), 0) == kIOReturnSuccess)
        {
            CFShow(propDictionary);
            CFRelease(propDictionary);
        }
        
    }
}

From past experience, it's very easy to get "disoriented" in the IORegistry and end up interacting with a completely different object than the one you're expecting. The code above makes it easy check that you're actually working with the object you think you are.

Related to that point, the other critical tool here "IORegistryExplorer.app", since it will let you see/find the object you're looking for and then working on matching from there. If you're not familiar with that app, you can find it "Additional Tools for Xcode" from our "More Downloads" section.

May I politely ask if you have a basic and functional Xcode project for both the dext and client sides that I could use as a reference?

As it happens, this is one area that actually has a good sample app. Take a look at "Communicating between a DriverKit extension and a client app". The service matching code is in the file "UserClientCommunication.c".

Moving to your code, this matching dictionary is wrong:

    ret = IOServiceGetMatchingServices(kIOMasterPortDefault, 
    IOServiceMatching("IOUserServer"), &iterator);

You're matching against all IOUserServer objects, most/all of which will not implement the relevant user client and you're also matching against the wrong class for "your" object. This is the matching code from the sample above:

// If you don't know what value to use here, it should be identical to the IOUserClass value in your IOKitPersonalities.
// You can double check by searching with the `ioreg` command in your terminal.
// It will be of type "IOUserService" not "IOUserServer"
static const char* dextIdentifier = "NullDriver";

...
    CFMutableDictionaryRef matchingDictionary = IOServiceNameMatching(dextIdentifier);
    if (matchingDictionary == NULL)
    {
        fprintf(stderr, "Failed to initialize matchingDictionary.\n");
        UserClientTeardown();
        return false;
    }

Expanding slightly on what was said here:

The value kIOPCIDeviceConnectType is just a number, the third parameter to IOServiceOpen called by your user-space client code. That number appears as the first parameter to NewUserClient_Impl in your dext. If your dext is your own, you can use any value you like, or ignore it entirely.

The "type" argument to IOServiceOpen is there to provide a convenient API hook for KEXTs that are implementing particularly complex UserClient, as it allows the same driver to return different user clients to the requesting client. Note that, for example, the same HID driver can open "kIOHIDServerConnectType", "kIOHIDParamConnectType", and "kIOHIDServerConnectType". This situation is NOT common in 3rd party drivers, in which case the correct value is "0", which your DEXT always returning the same value.

This is my first time working on dext development, I always ask Copilot or ChatGPT for help, but their answers are mostly non-functional code, which is truly frustrating.

Unfortunately, this is a very difficult development area to jump into and one I don't really have any simple answer to. Driver development has never been easy and DriverKit has not improved that situation. The one suggestion I would offer here it to take a bit of time to become familiar with IOKit. Fundamentally, much of DriverKit design is either directly copied or predetermined by IOKit, so understanding IOKit can help you understand DriverKit.

More to the point, IOKit original documentation is quite good, particular when it comes to explaining the broader architecture and design. In terms of specific starting points, "IOKit Device Driver Design Guidelines" was the original "entry point" document, which then point to "IOKit Fundamentals" (KEXT APIs) and "Accessing Hardware From Applications" (user space).

Note that, as far as I can tell, basically everything IOKit related in "Accessing Hardware From Applications" is effectively current, accurate documentation. We've add GCD callback support and a few other convenience methods, but otherwise the API is completely unchanged since it was introduced in macOS 10.0.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you so much, Kevin Elliott! I’ll definitely take the time to dig into the IOKit and Kext architecture docs you mentioned. It might take me a while to go through everything, if I have any question, I'll be back and ask for some help.