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.

Our website uses cookies on your device to give you the best user experience. By using our website, you agree to the placement of these cookies. To learn more, read our privacy policy. Read Privacy Policy