On Wed, 15 Sep 2004, Andrew Gallatin wrote:
>
> Godfrey van der Linden writes:
>
> Wow! Thank you for the detailed response. Here is my first round of
> questions. Please bear with me. I'm a clueless moron when it comes
> to IOKit..
>
> > Here you probably would just have a single property to compare that is
> > some sort of type of the nub, I suggest a property like {
> > edu_duke_cs_NubType = Ethernet; }. Your implementation of
> > matchPropertyTable would then come down to (This is all of the matching
> > you need for a single key match, pretty cool huh!)
>
>
> This {edu_duke_cs_NubType = Ethernet; } somehow ends up in xml
> in the edu_duke_cs_MPIEthernet.kext/Info.plist file, right?
Yes, it would go in the edu_duke_cs_MPIEthernet personality dict (inside
IOKitPersonalities). You can add pretty much whatever you like to there.
The whole thing would look like (ASCII formatted):
CFBundleIdentifier String edu.duke.cs.MPIEthernet
IOClass String edu_duke_cs_MPIEthernet
IOProviderClass String edu_duke_cs_MPINub
edu_duke_cs_NubType String Ethernet
(add IOKitDebug to taste)
> > bool edu_duke_cs_MPINub::
> > matchPropertyTable(OSDictionary *table)
> > {
> > if (!super::matchPropertyTable(table))
> > return false;
> > else
> > return compareProperty(table, gMPINubTypeKey);
> > }
>
> This gets called by the matching system automatically, right?
> All I need to do is override this function to have it called?
Yes.
> And gMPINubTypeKey is just a string, yes?
It can be anything you like but in this example it's a string. Actually
for compareProperty I think it has to be a string. What that function does
is get the value for the key (gMPINubTypeKey) from the table you passed
in, and compare it to the value for the same key in your own properties
(i.e. in the nub's properties). Note that if the driver that is being
considered doesn't have the key then compareProperty will succeed, so make
sure you include it in all the personality dicts or else they will fight
for the nub...
> > // Get the master nub creation table from our properties
> > // BTW there is no need to do a copyProperty as we can rely on our
> > properties
> > // being valid until we return from start, after that all bets are
> > basically off though
> > // you have been warned.
> > OSArray *nubList = OSDynamicCast(OSArray,
> > getProperties(gMPIMasterNubListKey));
>
> This (magically) comes from some xml in the
> edu_duke_cs_MPIMaster.kext/Info.plist, right?
Yes. From its personality dict. You would add an array containing all the
property dicts of the nubs you want to create to the master's personality
dict. Something like:
CFBundleIdentifier String edu.duke.cs.MPIMaster
IOClass String edu_duke_cs_MPIMaster
IOProviderClass String IOPCIDevice (good example of a nub that)
IOPCIMatch String 0x10101010
edu_duke_cs_NubList Array
0. Dictionary
edu_duke_cs_NubType String Ethernet
1. Dictionary
edu_duke_cs_NubType String Serial
etc. etc. etc.
> It would help me tremendously if you could give examples of what the
> matching properties and the nub lists should look like in xml. This is
> something that I've never been able to figure out (I pass parameters
> to my current driver via nvram.. PE_parse_boot_arg())
Well, that's in ProjectBuilder/PropertyListEditor format, but I hope it
helps a bit :)
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. Then compare that string with isEqual in the matchPropertyTable
(after getting out the corresponding string, and making sure it exists and
really is a string).
> Thanks,
>
> Drew
{P^/
_______________________________________________
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
