Hi,
I missed this discussion. I am not sure why you had the kind of requirement.
I have never seen that multiple Logical Units are required by a single
function or service. I couldn't find a reason why it is needed. What kind of
function needs to support multiple logical units?
Thanks,
Hitoshi
> -----Original Message-----
> From: Atsushi_Nakamura [SMTP:atsnaka at bsd.canon.co.jp]
> Sent: Tuesday, March 17, 1998 5:18 PM
> To: ALAN_BERKEMA at hp-roseville-om2.om.hp.com; rturner at sharplabs.com> Cc: p1394 at pwg.org> Subject: RE: P1394> units and logical units definition
>>> It would help to convince me (and probably others)
> that we are going the right way,
> and that everybodyis in synch. if we can :
>> 1. Confirm that the current usage of SBP-2 unit(directory)s and
> LUNs are consistant with the idea ("with the spirit")of units
> and LUNs defined in the SBP-2 spec.
>> >Note that SBP-2's concept of a printer certainly does not match
> >well with our devices. Disks are easily modeled. Scanners are
> >fairly easily modeled. Printers definitely are not.
>> As Greg mentioned, printers are modeled differently(more complex)
> from disks, and I think we are starting to define a new usage
> of SBP-2 units and LUNs in the current printer profile 0.1d that are
> different from other SBP-2 devices.
> (where 1 (printer) function is comprised of multiple units
> of the same transport protocol (PWG profile over SBP-2) within
> 1 node, and a combination of specific LUNs across these differnt
> units need to work simultaneously to achieve the (printer) function.)
>> Greg (Shue)'s explanation about an example of a printer model
> by considering logical units as a service (the cuurent profile0.1d) made
> sense within itself, but the question whether that usage is the
> intended usage or not has not been answered. There also is the issue
> on how to match up the LUNs
>> Eric says;
> >Even if each of those models is allowed by SBP-2, I think
> >the first one (a single unit with multiple LUNs) is both more
> >in the spirit of SBP-2 and more in the spirit of 1394.
>> The above comment increased the magnitude of my concern.
> I think this is a question of how the SBP-2 people intended
> units and LUNs to be used, so confirmation with (or a comment from)
> a SBP-2 expert would help.
>> 2. Confirm that the current usage of units(and LUNs) are consistant
> and "in spirit" with 1394 and 1212 (and other protocols aside from
> SBP-2.)
> Same as above, other protocols(such as AVC/FCP, DPP/Thin,
> Conf.camera spec. ) achieve the functionality within one "1212"unit.
> (Services are MUXed within the transport and above)
> The current profile will be the first of it's kind to achieve a
> functionality by using differnt LUNS across different "1212" units so
> there is a possiblity that the 1394 PC printer may look "odd"
> in the 1394 world.
>> 3. Confirm within PWG that this is the way to go.
> As I mentioned, the discussion about desires for mutiple
> independent channels within 1 LUN is still continuing, so I also agree
> with
> Alan that this is still hazy.
>> 4. Lastly,
>> > I think a detailed picture matching services to Unit Directories to
>> > LUNs might help.
>> I agree with this idea.
> Modelling a printer application may be out of the scope of the profile,
> but I think an example of a what a "basic" printer should look like
> will help understanding (even within PWG to keep everyone in synch !)
>>> > Would be nice, schedule could be tight.
> > How about 3/19 at 4:00PM?
> >
> I won't make this, but please go ahead if this schedule is reasonable
> for everyone else.
> I also apologize for not being able to contribute face-to face.
>> Ats
>>>> At 11:17 98/03/17 -0800, ALAN_BERKEMA at hp-roseville-om2.om.hp.com wrote:
>> > > I thought we had a pretty firm idea on the handling of logical units.
> >
> > From the discussion it still seems hazy to me.
> >
> > I think a detailed picture matching services to Unit Directories to
>> > LUNs might help.
> >
> > > Does this discussion require clarification of the current profile
> > > document, for full understanding?
> >
> > Absolutely.
> >
> > > Also, is there need for a teleconference on this or any other subject
> > > prior to the next face-to-face meeting?
> >
> > Would be nice, schedule could be tight.
> > How about 3/19 at 4:00PM?
> >
> > 3/20 could be bad for folks in Japan.
> > 3/23 is due date for the next rev of the spec.
> >
> > Randy
> >
>> -----------------------------------------
> Atsushi Nakamura
> -----------------------------------------
>> BJ Technology Development 22,
> Canon Inc.
>> 53 Imai Kami-cho
> Nakahara-Ku, Kawasaki-shi
> postal no. 211
>> tel:+81-3-44-733-6111(ext.5593)
> +81-3-44-739-6634(direct)
> fax:+81-3-44-739-6756
> email(1):Atsushi_Nakamura at cbj.canon.co.jp> email(2):atsnaka at bsd.canon.co.jp> -----------------------------------------