CODEWITHSUNDEEP
macosaudiokerneldevice-driveriokit
lychee
lychee

Reputation: 1851

IOResources class

All virtual device drivers who don't control any hardware devices seem to match on IOResources as the IOProviderClass.
Apple says that drivers that match on IOResources gets attached to the root of the IORegistry to get system-wide services like BSD kernel and etc...available to the driver.
What I dont understand is how does your driver gets called by the system since the system doesn't know what device you are controlling? For example how can a virtual audio driver get access to the system audio mix and hardware sample buffer without even attaching to it?
Since I couldn't find any information on the IOResources class I'm asking here

Upvotes: 3

Views: 934

Answers (1)

pmdj
pmdj

Reputation: 23428

I think the answer to your question boils down to the inherent contradiction in what you're asking:

All virtual device drivers who don't control any hardware devices seem to match on IOResources

vs.

What I dont understand is how does your driver gets called by the system since the system doesn't know what device you are controlling?

Either there's a real device to control, or there isn't, when it's a virtual device driver. In the case of a real driver, the provider will be a nub or device object, such as IOPCIDevice, IOUSBDevice/IOUSBHostDevice, IOUSBInterface/IOUSBHostInterface, and so on. The provider of your driver is the device your driver is controlling.

At the other end, each driver advertises what services it provides to the operating system, other kexts, or to userspace processes. This is signaled mainly by the (super)class type of your driver's main object or any nub objects it creates and registers with the I/O Registry. Clients which understand these interfaces will in turn match the driver's objects as their providers.

Your example of audio drivers actually demonstrates 2 ways this can work. OS X's audio subsystem mostly runs in user space - specifically coreaudiod. Since OS X 10.8, that includes audio device drivers themselves too, although the deprecated IOAudioDevice/IOAudioEngine kernel API still exists and Apple ships drivers which use it as of OS X 10.11.

In a legacy/kernel audio driver, your driver will implement subclasses of IOAudioDevice and IOAudioEngine and possibly some other classes. When instances of these classes are registered in the I/O registry, the Core Audio Daemon detects this via the service matching mechanism, and creates user clients for communicating with those kernel objects. Core Audio will match any objects which conform to the IOAudioEngine interface - I think this is the question you're asking.

In a modern audio driver, the Audio Server HAL plugin bundle's Info.plist contains the I/O kit matching dictionary. It might directly match a system-provided provider class, such as an IOUSBInterface, if the device can be driven directly. For a PCI device, you'll likely need a custom kext to do the memory-mapping and interrupt handling. This kext will most likely simply subclass IOService, nothing more specific than that, and provide its own user client class. The HAL plugin will then match on that kext's specific driver class name, and open a connection to it with the custom user client class.

I hope that answers your question?

Upvotes: 5

Related Questions