[t10] parameters in the control byte

Pat LaVarre LAVARRE at iomega.com
Mon Mar 24 07:04:24 PST 2003

* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
> From: T10 Document Administrator [mailto:lohmeyer at t10.org] 
> Sent: Sun 3/23/2003 12:00 AM 
> Subject: Recent T10 documents uploaded since 2003/03/16


> What is architectural about SAM-3 CDB definitions?
> (by: Ralph O. Weber)
> T10/03-005r1   Uploaded: 2003/03/18   71895 bytes
> ftp://ftp.t10.org/t10/document.03/03-005r1.pdf


> Only two parts of the CDB are of any interest to
> the architecture:
> () The OPERATION CODE field - If there is a command
> then there must be an operation code; and
> () The CONTROL byte - Careful inspection shows that
> the CONTROL byte is the architecture’s wholly owned
> field in the CDB, exercising control over linked
> commands and ACA (serious architectural task
> management stuff).

"Wholly owned"?

Rumour tells me we find alive & well the 1996 SFF 8020i r2.6 tradition of passing parameters in the Control byte, e.g. in the byte 9 Format bits of op x43 Read TOC in place of the byte 2 Format bits.

Can that reality be in dispute?

> [SPC-3 4.3 The Command Descriptor Block (CDB)]:
> Control
> The contents of the CONTROL field are defined in
> SAM-3 SAM-2. The CONTROL field has a consistently
> defined meaning across all commands.

Nice, pretty, merely public, merely standard, theory.

Pat LaVarre


* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list