When PWG representatives went to Redmond, Microsoft said that
their driver only supports LUN zero. They also said that LUN
zero needs to be directly mapped to a higher layer, because they
won't support dynamic LUNs.
So, we should think of LUN zero as being "allocated".
NOTE: Someone (Brian?) in VA. said that Microsoft's driver
will be extended to support more LUNs. There was a comment made
(from the Microsoft rep?) that Microsoft still will not support
dynamic LUNs.
>
>
> 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@sdd.hp.com
> >----------------------------------------------------------------
> >
>
>
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------