In Mac OS, the SBP-2 services are merged with the basic 1394
services. SBP-2 is not a separate layer that hides 1394; instead
SBP-2 services are available alongside basic 1394 services. So a
driver can use efficient SBP-2 transfers, while still directly
accessing a device through 1394 (if it wants to). Maybe this is
also true in Windows, but from the restrictions John mentioned,
it sounds like there may be room for improvement.
It would be a shame to define awkward or inefficient peripheral
protocols just because of software limitataions in an OS. Software
can always be fixed, while poor protocols seem to have long lives.
--------------------------------------
Eric Anderson ewa@apple.com
Apple Computer, Inc. 408-974-8187
--------------------------------------
>> Hi everyone,
>>
>> I talked to George C. about the three possible ways we were considering
for
>> setting connection parameters:
>>
>> 1. Using command-set dependant management commands. There is no way
>> for the class driver to cause the SBP-2 driver to send these, so I guess
>> they are out.
>
>Too bad.
>
>> 2. Using additional registers in the command agent register block.
>> There is no way for the class driver to discover these addresses or to
>> deliver requests directly to the 1394 bus driver, so again no luck.
>
>Oh well.
>
>> 3. Using commands in the normal command stream. This will work (as we
>> knew in Monterey), so we'll have to figure out a way to ensure that the
in
>> and out queues are both idle when they are issued (but we really needed
to
>> do that for 1 & 2 as well).
>
>Any progress on getting the Device Type to be dependent on Command_Set?
>
>
>--
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division gregs@sdd.hp.com
>----------------------------------------------------------------