<<1. I agree with David's observation that two ORBs (one read, one write) can
be used instead of a bidirectional ORB. A device is free to fetch both ORBs
and execute them in whatever order it likes, including simultaneously. A
device or device class can mandate that such ORB pairs be provided, even
though SBP-2 does not require it.>>
It seems to me that the use of unidirectional ORB's is essentially a
hold-over from SCSI habits of DATA IN or DATA OUT on a single command. It's
not surprising that SBP-2, thus far, addresses this model well---but perhaps
we should move forward.
Two coordinated ORBs is little more than a 64-byte bidirectional ORB that
takes two Serial Bus transactions to fetch! Given the lack of scalability for
arbitration times at faster and faster speeds ('specially for small packets)
I think we ought to avoid the unnecessary fetch.
<<2. I agree with John that the bidirectional ORB will be difficult to deal
with in software. Even though the SBP-2 layer is thin, there are complex
virtual memory issues, and having a special ORB with two payloads will
complicate that.>>
This is not some Pandora's box that is being opened, with n-directional ORBs
in our future. "Complex virtual memory issues?" Are you suggesting that
operating systems today have *no* API's in which more than one user buffer is
presented and must be locked down? I think the bidirectional ORB is
*different* to deal with in software and not all that difficult. The problems
of coordinating two-in-one ORBs (the paired ORBs David mentions) may be more
difficult than those of dealing with two buffers.
Peter Johansson