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

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

Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
Wed, 18 Feb 1998 09:13:43 +0900 (JST)

Just clarification ....

On Tue, 17 Feb 1998 14:35:26 -0800 (PST)
Greg Shue <gregs@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@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.