Reggie --
From what I have read I want to base this off an
IOBlockStorageDevice. Is this the best choice or should I base my
driver off some other class?
Yes, it is the best choice.
Is there any example code showing how to do something simple like
implement a ram drive and have it attached to the file system stack?
If IOBlockStorageDevice is the best class, then is it as simple as
creating my own versions of the various virtual functions?
Override the virtual functions, yes. After you allocate, init, and
attach your subclass of IOBlockStorageDevice, all you need to do is
call registerService() on it. IOKit will handle the rest.
Something like this (error checking removed for brevity):
IOService * mySubclass = OSTypeAlloc ( MySubclass );
mySubclass->init();
mySubclass->attach ( this );
mySubclass->registerService();
mySubclass->release();
How do I let the system know I want this to tie in to the rest of
the file system stack, for example I see myself writing a single
driver to handle both the transport and physical interconnect
layers(will separate later), but how does the system know to tie
these into the Device services layer above?
There's no reason to separate your driver into two layers if it's not
required. By following the example above (with added error checking),
IOKit will find your subclass of IOBlockStorageDevice and match the
appropriate driver (IOBlockStorageDriver). IOBlockStorageDriver will
make calls into your IOBlockStorageDevice subclass to find out the
media block size, number of blocks, etc.
Sorry for all the newbie questions, but this is my first driver in
the desktop word, I come from a much simpler embedded world and I'm
not use to starting with so much work done for me.
Good luck!
-- Chris
------------------
6 Infinite Loop
M/S 306-2MS
Cupertino CA 95014
phone: (408) 974-4033
fax: (408) 862-7577
email: email@hidden <mailto:email@hidden>