How the solution B works? (Re: P1394> 1284.4 over SBP-2)

How the solution B works? (Re: P1394> 1284.4 over SBP-2)

Akihiro Shimura shimura at pure.cpdc.canon.co.jp
Tue Feb 17 19:13:43 EST 1998


Just clarification ....


On Tue, 17 Feb 1998 14:35:26 -0800 (PST)
Greg Shue <gregs at sdd.hp.com> wrote:
(snip)


Message below is not from me. It's from Nagasaka-san.


> [Akihiro Shimura]


[Fumio Nagasaka]


> > I would like to introduce these rules shown below,
> > 1)      The initiator clear Unsolicited_Status_Enable register to forbid
> > the target
> >         to issue unsolicited status which says "Data Available", while
> > the initiator
> >         is appending new ORBs in the list.
> > 2)      The target shall observe Unsolicited_Status_Enable register,
> > whether or not it is
> >         set to one, before it scans linked list of ORBs.
> > 3)      When the target found Unsolicited_Status_Enable register is set
> > to one,
> > and there is no in-ORB in the list, then the target may send unsolicited
> > status.
> > 
> > Then the initiator will not generate too many in-ORBs in the list.
> 
> [Greg Shue]
> There are some problems with the rules:
> 
>   Rule 1 changes the definition of SBP-2.  SBP-2 does not provide a
>   mechanism for the initiator to clear the Unsolicited_Status_Enable
>   register.  A write of _any_ value to the register enables
>   unsolicited status.
> 
>   Rules 2 & 3 assume that an Unordered processing model is used.
>   See my previous comment.
> 
> Because the ORDERED processing model is used, the rules are unnecessary.



--
 Akihiro Shimura (shimura at pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.




More information about the P1394 mailing list