As far as I understand, the "another unsolicited status" will not
happen in this scenario by the definition given by Greg because the
target is already in "Data Available" state. (Greg, thank you for the
> I would like to introduce these rules shown below,
> 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?
I'm not sure if I understand your question, but the functionality
equivalent to multiple logical channel is already done in the SBP-2
only solution (option B) via unit architecture. If the target does NOT
behave as expected by the initiator, like asynchronous notification,
"aborting task"(which implies subsequent retry) will be necessary to
keep each direction independent. To avoid the use of "aborting task"
while keeping each direction independent, I thought it may be natural
to allocate two independent links(logical units) for down-link and
up-link instead of using "aborting task".
On Thu, 12 Feb 1998 10:24:21 -0800 (PST)
Greg Shue <email@example.com> wrote:
> Haven't we been down this road before? (Yes, and rejected it.)
I don't remember if this(one initiator makes two logins for each
transfer direction without using 1284.4) is addressed already or not.
Is this addressed in last August (Redmond) meeting?
-- Akihiro Shimura (firstname.lastname@example.org) Office Imaging Products Development Center 3 CANON INC.