On Wed, 15 Sep 2004, Godfrey van der Linden wrote:
> G'day All,
>
<snip>
>
> The last thing to do with the Master driver is to publish it as a
> kernel extension library. To do this you add the
> OSBundleCompatibleVersion property to your Master Drivers Info.plist
> (at the top level, not in the IOKitPersonality Property)
Yes that took me ages to figure out! It seems you need to have this in any
kext that another kext wants to depend on (it's the lower bound that the
value in the OSBundleLibraries array in dependent kexts is compared to).
<snip>
>
> Notes:
> 1> It is possible to short circuit the entire nub creation by calling
> registerService() on your master driver and using IOMatchCategory to
> allow multiple drivers to match against it. This is sort of easier but
> I find that once I have created the nub class all sorts of interesting
> things end up living there it is just too convenient.
That was what I thought the second option in your original reply was going
to be! I really didn't expect you to suggest using nubs in this case. It
seems to me, that where you have a number of identical outlets (identical
to you) that you scan and detect, that would be the place to make nubs
(i.e. when you are/have a bus).
But where there are just a number of aspects to your driver, and the main
reason you're splitting it up is so that you can inherit from >1 family
drivers (ok there might be some modularity reasons too), then using
different IOMatchCategory's would be the recommended way.
For this kind of multiprotocol driver it would definitely be the easiest,
and the name IOMatchCategory even makes sense - are you matching on the
'Ethernet' part of your driver of the 'Serial' part of it, etc.
Of course the number 1 reason for me would be that you don't have to write
any code at all! The only change to your (master's) start routine is to
call 'registerService', and the protocol drivers get automagically matched
and started with you as their provider - a quick metacast and they can
call any (public) functions in your class they like. You don't have to
make up an interface in the nub ... or leap over it to get to the real
provider.
I've used both nubs and direct matching in my drivers, each in the
situations where that technique seemed to make the most sense.
> 5> Teardown. I suggest in development you provide some 'setProperties'
> ioctl that can create and terminate nubs. This will make you
> development life quite a bit easier. Do remember though that your
> slave driver should open() their nub and close it when they have
> finished.
... or just put the slave drivers in a different kext and load/unload it.
> 6> I have ignored power management as that is a whole different can of
> worms.
:)
While I'm at it, I'd just like to ask about the way you made nubs in the
code snippet you posted. You basically went nub->attach then
nub->registerService. i.e. you didn't start it (unless one of those
methods starts it...?) When I make nubs I go nub->attachToParent followed
by nub->start. The start method of the nub class (after a bit of minimal
setup) does the registerService. Any comments or things I should be aware
of that I'm doing wrong? It seems to work (even power management :)
{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
