It's the same idea, but at a different scope. As I was
working out the draft I knew we needed to uniquely identfy
each command, no matter what sequence it arrived in. These
didn't degrade to being sequential until parameters could
only be read before openning a connection.
(Otherwise we may end up with the problem of needing to
read a parameter to do error recovery before we can continue.
The command to read a parameter gets put into the command
stream before continuing the previously aborted commands.
Does this command get the first sequence number expected
by the target and associated with a previously queued command,
or does it get a tag which may be out-of-sequence?)
> 2. Do you really believe a target device can fail to
> receive an ack-packet?
Yes. Do I really believe that a target device can fail to
receive an ack-packet without receiving a bus reset? Yes,
but it's _extremely_ unlikely unless it's during product
development. In that case, all bets are off. :-)
> 3. I would like to suggest three commands listed below;
> TRANSPORT_I2T_ABORT
> TRANSPORT_T2I_ABORT
> TRANSPORT_ORB_RELEASE
>
> 3.1. TRANSPORT_I2T_ABORT
> An initiator requests a target to stop ORB fetching,
> and solicits the target to reply STATUS block when
> the last ORB had been executed.
I probably don't understand this one.
Since we're using the UNORDERED model, all the ORBs on the
task list have been fetched by the target as soon as they
are placed on it. There is no point to issuing this command.
This command would really need to be issued as a vendor-specific
Management Agent command, since it needs to be executed
asynchronously to the two ordered execution queues or
else a third queue needs to be defined.
Using the ABORT TASK management function defined by SBP-2
beginning with the last task in the queue will do the same
thing if you want a queue-specific function.
I don't think this provides any additional usefulness and
significantly changes the device model. What am I missing?
>
> 3.2. TRANSPORT_T2I_ABORT
> A target requests an initiator to stop appending new
> ORBs on outstanding linked list. The initiator may
> invoke "close" command when it received STATUS bock
> associated with the last ORB.
I don't understand this one either.
A target knows what is the last ORB on the queue when the
target's transport client gives the appropriate indication.
We can make a target capable of indicating a direction close
synchronous with a TRANSPORT_T2I_DATA completion. All subsequent
TRANSPORT_T2I_DATA commands are completed with a status of
connection closed.
I don't see the need for this command either. Can you explain
this one better?
> 3.3. TRANSPORT_ORB_RELEASE
> A target request an initiator to release specified ORB
> without completion STATUS block.
"I don't understand this one either."
This command would really need to be issued as a vendor-specific
Management Agent command, since it needs to be executed
asynchronously to the two ordered execution queues or
else a third queue needs to be defined.
This sounds identical to ABORT TASK.
What am I missing?
I don't want to re-invent and re-implement SBP-2. The goal is
to supplement it as little as possible.
-- Greg Shue Hewlett-Packard Company All-in-One Division gregs@sdd.hp.com ----------------------------------------------------------------