Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Going up the provider chain to call a higher level method
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Going up the provider chain to call a higher level method


On Oct 15, 2007, at 11:33 AM, Thomas Tempelmann wrote:

While my solution with a kext subclassing the IOCDBlockStorageDriver, and
then actively matching for a particular USB device, works fine for me,
someone has risen the concern that this puts unnecessary strain on the
kernel.

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- >ejectMedia(),
there is no such method on the deeper level of the USB Mass Storage classes.
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 inefficient. _______________________________________________
Do not post admin requests to the list. They will be ignored.
Ata-scsi-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >Going up the provider chain to call a higher level method (From: Thomas Tempelmann <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.