Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: matching for a shim driver

G'day All,

Let's talk about the match category solution then.

As you can see from the 'formal' solution I presented in my previous emails I didn't cover the 'simpler' solution first. This was done deliberately as it has some issues and now is a good time to discuss those I guess.

First, Drew the IOMatchCategory is a fundamental part of the matching process. When IOKit is given an IOService to match (by calling registerService()) it creates a list of candidate drivers based upon the IOProviderClass of all of the IOKitPersonalities that live in /S/L/E & /S/L/E/*.kext/Contents/PlugIns. Once it has the candidate list it excludes all of the drivers that fail the passiveMatch (implemented by the matchPropertyTable() function). Finally the list of drivers is sorted by IOMatchCategory, btw if there is no IOMatchCategory declared then the default IODefaultMatch is assumed, and then for each category the list of drivers are given the oppotuntiy to 'start()'. Once a driver returns a 'true' then that match category is done and the matcher moves onto the next one.

Thus if more than one nub calls registerService then each one gets matched totally independently. Be warned this can cause multiple instances of the same driver to exist, (this is a feature not a bug, see archives for the arguments though)

The problem with Match Category is that you can only publish one node per category, cleanly that is. Also it complicates the 'open()' implementation in the Master driver. Now neither of these problems are insurmountable. JohnD has discussed the advantages in simplicity.

One last thing, I'm not sure that I agree with JohnD's statement
Note that a much easier way to do the above even with nubs would be to just pass the string that you want to match against into the init method of the nub. Hardcode them! It's not like your hardware is going to grow new chips.
This statement is right as far as this particular driver is concerned, However my experience is that the hardware evolves and the driver also evolves. I find that Hardware designers are sort of like software engineers and one of the easiest and most powerful things to do is to add multiple cells to the FPGA. If you design the Master driver properly you can describe these additional cells in the OSArray in your personality and not have to change the driver at all.

Also hardc oding isn't really that nice a solution in anycase. It requires less code to walk through an array in your matching IOKitPersonality then it takes to hard code the creation of the nubs one at a time.

BTW this isn't theoretical. I really have developed a driver where the Master driver didn't have to change when a new cell was added. We just defined the parameters in the personalities array and matched the next level driver. This was so we could use the same drivers for 2 different types of hardware (pro & prosumer).

Final note about 'gMPINubTypeKey' is a symbol declared as follows

const OSSymbol * gMPINubTypeKey = OSSymbol::withCStringNoCopy("edu_duke_cs_NubType");

Almost everything in IOKit that seems to take a CString or even an OSString is probably really taking an OSSymbol. I find that it is better and slightly more efficient to create the symbols at 'init' time. (See an earlier email from me discussing the use of C++ static constructors for initialising global static data structures. See also IOSerialFamily/IOSerialFamily.kmodproj/IOSerialBSDClient.cpp

Godfrey
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden

This email sent to email@hidden
References: 
 >matching for a shim driver (From: Andrew Gallatin <email@hidden>)
 >Re: matching for a shim driver (From: Godfrey van der Linden <email@hidden>)
 >Re: matching for a shim driver (From: Andrew Gallatin <email@hidden>)
 >Re: matching for a shim driver (From: Godfrey van der Linden <email@hidden>)
 >Re: matching for a shim driver (From: John Dalgliesh <email@hidden>)
 >Re: matching for a shim driver (From: Andrew Gallatin <email@hidden>)
 >Re: matching for a shim driver (From: John Dalgliesh <email@hidden>)
 >Re: matching for a shim driver (From: Andrew Gallatin <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.