On Oct 15, 2007, at 11:33 AM, Thomas Tempelmann wrote:
While my solution with a kext subclassing the
then actively matching for a particular USB device, works fine for me,
someone has risen the concern that this puts unnecessary strain on the
Based on what you've described, this is simply not the case. Active
matching is on the whole quite efficient, and I wouldn't expect their
to be _THAT_ many CD devices on any machine in the first place.
Unless your doing something really strange, I don't see how their is
any harm leaving things just the way they are.... If anything, moving
down the stack might even make things worse, not better- most users
have a lot more USB devices than CD devices, so you risk having to
filter yourself out a lot more often than you would if you just
stayed a CD device!
While with my IOCDBlockStorageDriver I can simply call this-
there is no such method on the deeper level of the USB Mass Storage
I would have to either:
a) find the IOCDBlockStorageDriver class instance that my Mass Storage
driver is a provider for, or
b) issue the ATAPI eject (stop?) command from that deeper level.
Either is possible.
For, A, look at in IOService.h and/or IORegistryEntry.h. There are
methods there for walking the tree programmatically. Be aware that
it probably won't work to walk the tree inside your start method- the
rest of the tree hasn't loaded above you yet, so you'll need to wait
for the stack above you to load before venturing forth.
For, B. Read the spec. It's been awhile since I did any digging
there, but the commands are well documented and should be hard to
find and replicate.
BUT. All this is academic- if your driver works, I'd stay in
IOCDBlock. Your not hurting the kernel any, and your not really
Do not post admin requests to the list. They will be ignored.
Ata-scsi-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: