Hi,
Alan wrote:
<<
I think Shimura san has some good points at the end of his message
that goes to the heart of what is still not clear with the option B
proposal. I think we need to work up some example scenarios and
explore exactly how this will work. Greg Shue got any ideas here.
>>Alan, I think Shimura san has pointed out one important thing here,…
Akihiro Shimura wrote:
<<
If target request data transfer by "Data Available" flag
in certain
status block, initiator will subsequently append "SND
data-in" ORB in
the current task list. It will be possible for the
target to check if
there is a "SND data-in" ORB in the task list BEFORE the
initiator
appends the "SND data-in" ORB. After finding there is no
"SND data-in"
ORB, the target may issue another unsolicited status
which indicates
"Data Available". By this status, the initiator may
append one more
(total two) "SND data-in" ORB in the task list. After
that, the
target will need to abort the excessive ORB.
Is this a way the SBP-2 only solution works?
>>
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.
Akihiro Shimura wrote:
<<
It seems natural to make two independent logins for each
direction,
one for down-link and another for up-link by using the
idea to map
them into logical units. Furthermore, by extending this
to allow to
allocate up-link in reverse fashion (i.e., the target of
down-link
makes a login to the initiator of down-link), the link
between two
devices will become symmetric if both ends have both
initiator and
target functionality.
>>It is interesting. I had same idea to use two logins in last summer. But
my reason was different.
If we use one up-link and one down-ink, can we use multiple logical
channels in each direction? Then how can we prevent *one simple
uni-directional data path* to be stalled?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to nagasaka.fumio at exc.epson.co.jp
-----Original Message-----
From: Akihiro Shimura
[SMTP:shimura at pure.cpdc.canon.co.jp]
Sent: Friday, February 13, 1998 12:05 AM
To: Greg Shue
Cc: p1394 at pwg.org; P1284_3 at lexmark.com; Larry Stein
Subject: Re: P1394> 1284.4 over SBP-2
On Tue, 10 Feb 1998 19:21:19 -0800 (PST)
Greg Shue <gregs at sdd.hp.com> wrote:
> > I await your responses.
>
> OK, here we go...
OK, I'll follow...
> Larry Stein wrote:
>
> > At this point in time we have apparently narrowed
our potential solutions
> > to the following:
> >
> > A- 1284.4 with SBP-2
> > B- New SBP-2 command set with SBP-2
(snip)
> As I understood it, the ability for 'a peripheral to
operate over
> various interfaces without requiring major
architectural changes
> to the product' is provided by meeting the specified
transport
> service requirements. As long as the transport
requirements are
> met, no architectural changes are required of the
product. Thus,
> the transport layers are all modular with respect to
the product.
I agree. This was original intent of the HPT which
Ueda-san and I
introduced from last June meeting.
(snip)
> Given all of this, I am compelled to support option B.
Basically, I also support to consider option B, but it
is still not
clear for me how the data transfer of each direction is
done
independently within single login in SBP-2 only
solution.
If target request data transfer by "Data Available" flag
in certain
status block, initiator will subsequently append "SND
data-in" ORB in
the current task list. It will be possible for the
target to check if
there is a "SND data-in" ORB in the task list BEFORE the
initiator
appends the "SND data-in" ORB. After finding there is no
"SND data-in"
ORB, the target may issue another unsolicited status
which indicates
"Data Available". By this status, the initiator may
append one more
(total two) "SND data-in" ORB in the task list. After
that, the
target will need to abort the excessive ORB.
Is this a way the SBP-2 only solution works?
I think that aborting tasks implies subsequent task
retries, and may
not be efficient.
It seems natural to make two independent logins for each
direction,
one for down-link and another for up-link by using the
idea to map
them into logical units. Furthermore, by extending this
to allow to
allocate up-link in reverse fashion (i.e., the target of
down-link
makes a login to the initiator of down-link), the link
between two
devices will become symmetric if both ends have both
initiator and
target functionality.
Any suggestions?
--
Akihiro Shimura (shimura at pure.cpdc.canon.co.jp)
Office Imaging Products Development Center 3
CANON INC.