P1394> Dynamic LUNs

P1394> Dynamic LUNs

Randy Turner rturner at sharplabs.com
Sun May 24 05:46:39 EDT 1998


I'm not sure what you are recommending in comment (B) below. If this came
up at the Virginia meeting, can someone elaborate as if LUN 0 for a
particular unit has been "allocated" by Microsoft or some other group?


Randy






At 05:03 PM 5/14/98 -0700, Greg Shue wrote:
>
>Here's some comments on the Dynamic LUN notes sent out by Alan.
>
>A)  I don't think the Dynamic Logical Unit Number scheme was
>    intended to _multiplex_ applications to device functions.
>    I think it is intended on providing the ability for a node
>    to establish a unique connection to identical instances of
>    a service without having to:
>
>      1-  Assign fixed LUNs for each service instance
>      2-  Crowd the Config ROM with redundant information
>
>B)  After discussions with folks from Microsoft, I would strongly
>    recommend NOT using LUN 0 (zero) for anything but a direct
>    connection to an instance of the transport client.  The LUN-server
>    could easily be identified in the Config ROM as belonging to
>    a different LUN.  (Since it's really a different service
>    than the transport client.)
>
>C)  The SBP-2 initiator and target drivers do not change a bit.
>    Reconnect proceeds normally.  The initiator and target SBP-2
>    drivers must already remember LUNs, EUI-64 values, and LoginIDs.
>
>D)  The SBP-2 driver probably will already map connections (LoginIDs?)
>    to a socket ID or some other appropriate OS mechanism.
>
>It still strikes me as a clean, simple way to get beyond the constraints
>of SBP-2 when appropriate.  Best of all, it's optional!
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>Office Products Division			gregs at sdd.hp.com
>----------------------------------------------------------------
> 



More information about the P1394 mailing list