Mac OS allows any number of LUNs per device. We will create an
entry in the "Name Registry" for each LUN and we will try to load
a driver for each LUN.
But, it is not required to use one driver per LUN. If you like, a
single driver can control multiple LUNs.
There is no limit to the number of LUNs, number of Logins, or the
number of active ORBs that one driver can use (other than system
memory size limits, and SBP-2 rules such as one Login per LUN per
node).
I would like to suggest that multi-LUN devices in which the LUNs have
different tasks (such as status, control, data, etc.) related to the
same common goal (such as printing) should make the LUN's somehow
different. This will help us to load the right driver for the right
LUN. For example, each LUN could have a different device_type in
the Logical_Unit_Number entry (7.4.11 or 7.5.4). Or you could even
use different Command Set Revisions or Spec IDs for each LUN,
depending
on what you think the best way to distinguish the functions is. Mac
OS is very flexible - it can match drivers based on any of these LUN
criteria. Even if you only want to use one driver for all the LUNs in
your device, it will be easier for us to find them for you if you make
them look different in one of these ways.
--------------------------------------
Eric Anderson ewa@apple.com
Apple Computer, Inc. 408-974-8187
--------------------------------------
>> Hi Eric,
>>
>> If 1394 PWG chooses =C5gconnections over multiple LUNs=C5h, does
new Mac OS
>> support device discovery which has a configuration ROM shown below?
>>
>> UnitDir --->[ LUN0, LUN1, LUN2, =C5c]
>>
>> And may our driver invoke =C5gLogin(s)=C5h to each LUN separately?
>> Does Mac OS register each LUN as a separated entity in the name
registry?
>> Thank you,
>> --------------------------------------------
>> Fumio Nagasaka
>> Epson Software Development Laboratory Inc.
>> Tel +81 268 25 4111, Fax +81 268 25 4627
>> E-mail to nagasaka.fumio@exc.epson.co.jp
>>
>> -----Original Message-----
>> From: Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
>> Sent: Saturday, October 17, 1998 3:56 AM
>> To: 'Greg Shue'; Nagasaka Fumio
>> Cc: p1394@pwg.org
>> Subject: RE: P1394> connection for Function or Service
>>
>> > A larger issue with "current PC OS" implementation may be how
>> > many outstanding requests can be supported at once by the SBP-2
>> > driver.
>>
>> I agree that it is a large issue with the implementation. But, it
is not
>> clear to me that the SBP-2 is required to handle multiple logins or
>> connections. Who cases multiple connections per a single login? I
think
>> we
>> should be able to handle multiple connection on a single login or
multiple
>> logins. These implementations are very different.
>>
>> Thanks,
>> Hitoshi
>>
>> -----Original Message-----
>> From: Greg Shue [mailto:gregs@sdd.hp.com]
>> Sent: Friday, October 16, 1998 8:40 AM
>> To: Nagasaka.Fumio@exc.epson.co.jp
>> Cc: p1394@pwg.org
>> Subject: Re: P1394> connection for Function or Service
>>
>>
>> > However, each service requires a multiplexed connection and
>> > each connection requires flow control and send/receive queues.
>>
>> Whether we multiplex connections over a login or have separate
>> logins, each service is accessed over a connection, and each
>> connection requires flow control and send/receive queues.
>> This is a non-issue in the decision.
>>
>> A larger issue with "current PC OS" implementation may be how
>> many outstanding requests can be supported at once by the SBP-2
>> driver.
>>
>> --
>> Greg Shue
>> Hewlett-Packard Company
>> All-in-One Division gregs@sdd.hp.com
>> ----------------------------------------------------------------