You are correct that interactions between other nodes are independent
of Win98/NT5.0.
>
>
> This LUN 0 allocation would only affect us if a Win98/NT5.0 host was the
> "target" in a particular config...I didn't think the Microsoft driver
> would interfere with us trying to access any arbitrary LUN on "another"
> node...(?)
>
> Randy
>
>
> -----Original Message-----
> From: Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent: Tuesday, May 26, 1998 9:37 AM
> To: rturner@sharplabs.com
> Cc: p1394@pwg.org
> Subject: Re: P1394> Dynamic LUNs
>
>
> SBP-2 says that LUN zero must exist.
>
> 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
> ----------------------------------------------------------------
>
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------