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 Andrew (and the Darwin Driver list)

Wow this is a wonderful question and now we can really show of the capabilities of IOKit.

There are two main options available, both of which are based on the same 'master' driver concept that you are currently using. The difference between the two options depend on how much flexibility you want with the different drivers that your card supports.

As an example I shall discuss an hypothetical MPI communications card. Let say it supports IP Networking, high speed serial and dedicated private MPI protocols. And lets say that your hardware isn't really multifunction, so much as you can just support a whole lot of different protocols between 2 instances of your card on the same fabric.

Step 1> write the Master driver.

This is a driver that doesn't really support any protocol but it does export functionality that your hardware supports so that the client drivers can be implemented. This driver is probably already written and is your IOService class.

Step 2>  Write the client drivers

These drivers are various subclasess that all use your master driver as a 'transport'. That is you write an IOEthernetController subclass, an IOSerialDriver subclass and your own UserClient subclass for your MPI interface.

Now here is the choice point

Choice 1 - IOKit matching solution > Your master driver publishes 'nub's that you client drivers match upon, one per protocol supported. These nubs would then provide the interface as 'providers' to your client drivers. (There is a bit of magic involved with creating and attaching a nub that we can discuss in a later email). I personally like this solution because I write my master driver in such a way that it iterates of an OSArray in the matching personality and creates a nub for each entry in the table. This allows me to slowly bring up a master driver one function at a time. Another advantage to this solution is that you can ship multiple kexts and only load those kext that are REQUIRED by the users configuration. Note when I do this I usually setup the User client to use a nub rather than the master driver directly, though if I remember correctly you are publishing a cdevsw driver aren't you?

So using the example it would create edu_duke_cs_apple_iokit_GenericNub classes that would be created with a property table pulled from an array of initial property tables kept in the master drivers IOKitProperties list. You would have one instance for the Ethernet protocol, one for the serial protocol and finally one for the user client (or BSD client) drivers to connect to.

Choice 2 - Hard Wired solution> Your master driver instantiates your client subclasses directly. That is it calls OSTypeAlloc() for each of the client drivers you support then your attach and start them explicitly. The advantage to this solution is it is simpler that choice one and it can't suffer from binary compatibility issues (i.e. the master and slave drivers always live in the same executable).

This is a broad brush outline of the solution, we can refine it as we go along in further emails.

Godfrey

On Sep 14, , at 13:46, Andrew Gallatin wrote:


I have a device which is much, much more than an ethernet card, but it
also is an ethernet card.  As it does not really fit any predefined
driver class, my current driver for it subclasses ioservice.

To handle the ethernet functionality of this card, I'd like to write
an ioethernetcontroller driver, rather than hooking directly into ifnet
like I did for the last version of the software.  I got kinda sick
of tracking each little change to the network system, and it would
be nice for the interface to appear in the gui tools...

FWIW, the real driver is in charge of all hardware, and the ethernet
driver will just call functions in the main driver to do most of its
work.   Its basically going to be a shim between iokit and the
platform-independant driver.



In reading the driver matching section of iokitfundamentals, it looks
like an iokit driver has to match on "something."  Eg, the system has
to find new "hardware", you can't just load your driver and have it go
looking for something to match on.  The match has to be initiated by
the OS finding something new.

Assuming this is correct, then I need to have the main driver publish
"something" that the ethernet driver can match on.  I think I need to
have each instance of the main driver publish one "something" for a
corresponding instance of the ethernet driver to match on.

Am I on the right track?  Can anybody suggest some sample code to read
which does something similar?  Can the ethernet driver match on
something published by my main driver IOService::publishResource() ?

Thanks,

Drew







 _______________________________________________
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


_______________________________________________
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>)



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.