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: Why is USB different from ATAPI and FireWire?

Tommy --

> With respect to the nub/driver architecture of the IOKit, would I be
> right to say that the USBMassStorageClass is doing it the "right" way
> and the ATAPI and FireWire are not (yet)?

No. IOUSBMassStorageClass is doing it the only way it CAN be done on
USB. Instead of actually implementing multiple LUNs which are part of a
target device, the USB Mass Storage people went down another road using
(I believe) multiple interfaces (Dan or Tim, jump in here if I am
incorrect).

> Can a FireWire target have multiple LUN's? (Sorry, I know
> next-to-nothing about FireWire).

Yes, but unfortunately, the FireWire layers on Mac OS X break up LUNs
instead of leaving it to higher (SAM) level drivers. They have to do
this for some devices such as cameras, but for the devices which follow
SPC, they should not. We are working with them to correct this in the
future.

> If so, it seems likely to me that in the near future, the FireWire
> SBP2 transport driver is going to have to do the same thing that USB
> Mass is currently doing. Would that be a correct assessment? Also
> IOSCSIParallelInterfaceProtocolTransport?

No. The IOFireWireSerialBusProtocolTransport will most likely move to
the way that things are done under IOSCSIParallelFamily in that the
SCSI Protocol Services piece creates an IOSCSITargetDevice (a new
object in SAM as of Jaguar) and it will handle breaking up LUNs.
IOSCSIParallelInterfaceProtocolTransport will not change and is
deprecated. However, the SCSI Protocol Services piece in
IOSCSIParallelFamily (IOSCSIParallelInterfaceDevice) does create an
IOSCSITargetDevice which farms out the LUNs.

> So, it appears that the only way that I would be able to provide this
> service (that logs all the CDB traffic for SAM devices) would be for
> me to provide drivers and personalities that replace the
> IOSCSIProtocolService providers in each of the transport families. Or
> am I being overly pessimistic?

We've been looking at ways to enable/disable logging levels at runtime
similar to how the USB Family does this. If you would like to help
contribute to this effort, we can speak off-list.

> I am imagining another alternative, that I'd appreciate hearing your
> comments on. It is to have the IOSCSIProtocolService providers in each
> of the transport families publish a property, PopulatedLUNs, an array,
> and have the IOSCSIPeripheralDeviceNub instantiate a generic LUN
> driver, whose purpose it would be to interrogate the LUN and publish
> the properties that IOSCSIPDTxyz match on (so, add an additional layer
> between the transport and the PDTxyz drivers). Or, in some other way
> to split out the interface between families from the business of
> interrogating the LUN.

This won't work in general. USB is the one wacky interface which
actually knows from USB commands that it has LUNs. The others
(Firewire, SCSI Parallel, Fibre Channel) use SPC commands to find LUNs.
Your idea would violate a layering principle we have established in SAM.

> I don't want to suggest that the IOSAMFamily should change just to
> make something work that I happen to be interested in. On the other
> hand, I'd like to see that the interface be consistent across all
> transport-provider families, so that I can think about this problem
> generally, and be less tied to doing different things based on the
> flavor of the transport.

Correct. This is what we have aimed to do with the IOSCSITargetDevice
object. ATAPI and FireWire will most likely move to this model in the
future.

> Right now, only USB Mass is different. But I think as multi-LUN
> support matures, it seems as though ATAPI will be the odd-man-out.

Correct. USB is different. Precisely because the standards committee
chose to do things differently from the rest of the T10 committees.
ATAPI will not be the odd-man-out because each SCSI Protocol Services
driver is able to return a maximum logical unit number. ATAPI will
simply return 0.

-- Chris

------------------
6 Infinite Loop
M/S 306-2MS
Cupertino CA 95014
phone: (408) 974-4033
fax: (408) 862-7577
email: email@hidden
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: Why is USB different from ATAPI and FireWire? (From: Tommy Knowlton <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.