Eric Anderson wrote:
> As part of a truly native SBP-2 printer profile, I would expect
> to include a sequence number or something in the ORB command,
> so that a target can be sure not to execute the same command
> twice. I would also allow a target to abort at any point it
> likes and communicate this to the initiator. For example,
> "I ran out of paper between commands 4 and 5 in ORB 1129
> and I flushed further execution. Tell me what to do now.".
>
Since I think we are talking about SBP-2, I will expand on the above
statement tohave meant the following. 'I ran out of paper after
completing command 4 in ORB 1129
and I flushed further execution. Tell me what to do now.'
I wanted to clarify that your original statement did not imply that
there could be
multiple commands per ORB. This in not allowed in SBP-2 (section
5.1.2).
In fact I believe the appropriate sequence would be the return of good
completion
status for ORB 1129, detection of the out of paper condition,
unsolicited status
transfer from target to initiator indicating the out of paper condition.
> --------------------------------------
> Eric Anderson ewa@apple.com
> Apple Computer, Inc. 408-974-8187
> --------------------------------------
>
> Greg wrote:
> > This is true if the tasks being processed by the target are
> > idempotent. (In other words, that they may be executed one or
> > more times and end up with exactly the same result.) This
> > feature is needed to support the following situation:
> >
> > - a task to be partially processed
> > - a Bus Reset to occur (which implicitly aborts the task)
> > - the task requeued on the list
> > - the task completely restarted
> >
> > I think this is an inheirent attribute of mass storage commands.
> > Unfortunately, printers are not.
> >
> > Sending a set of commands which are larger than the printer can
> > buffer forces the printer to process some commands before they
> > are all received. If a Bus Reset occurs, then either the printer
> > must validate that the same ORB was requeued and try to resume
> > from the last valid offset fetched, OR the protocol can guarantee
> > that the ORB's data block has been completely transferred before
> > the data is processed. The first case is difficult at best, the
> > second is easy and provides idempotency at the cost of
> > negotiating the maximum sizes of the data blocks referenced by
> > the ORBs.
> >
The printer fetches the ORBs from the initiator. The printer is aware
of its
buffer limitations and I assume (maybe incorrectly) that it should take
its buffer
limitations in to account when determining when to fetch the next ORB.
If a bus reset occurs, the printer will clear any pending tasks and
transition to the
reset state. The initiator knows exactly which ORBs in the task set
were executed
based on the return of completion status. Therefore it should be clear
to the
initiator what ORB address to use in a write to the ORB fetch pointer
CSR to continue
execution of the task set after the fetch agent is initialized.
> > So, it's easier for the initiator to be aware of the transport
> > packet sizes supportable by the target than it is to work around
> > the Bus Reset problem by another mechanism. If you have a better
> > suggestion, I'll certainly consider it.
> >
> > "Need" is relative to the context. In this thread, we're talking
> > about using SBP-2 for printing services.