READ (6), WRITE (6), et al.
mj at feral.com
Thu Dec 9 07:17:12 PST 2010
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1012093_f.htm">HTML-formatted message</a>
As soon as you obsolete commands, testing will stop- as you clearly
would like it to. It's already bad enough with non-obsoleted commands.
You are trading costs that manufacturers incur to costs that users with
legacy systems incur. Oh, and yes, you are lightening costs this body
incurs by having to maintain interactions with older specifications
which, like arterial plaque, drive us toward an untimely death.
> In SBC-3, I favor obsoleting the 6-byte versions but would keep the
> 10-byte versions. The 6-byte commands have too many special cases:
> transfer length of 0, special DIF rules, lack of force-unit-access and
> group support, etc. implementing and testing these consumes
> development time, test time, and code space in targets and SAT layers.
> Remember that "obsolete" just means "defined in a previous version of
> the standard." Targets can continue to offer these commands as long
> as there is a perceived need. If another new feature like DIF comes
> along, though, the standard won't advise how to handle the obsolete
> commands in light of the new feature. As documentation becomes harder
> to find and targets start dropping obsolete features, initiators
> should feel pressure to stop using them. This can take years (has
> usage of the Format Device mode page and Rigid Disk Geometry mode page
> been eradicated yet?).
> SBC-2, published over 5 years ago, included the recommendations to use
> 10-byte rather than 6-byte commands. It also had DIF support rules.
> Maybe SBC-4 and SPC-5 can exorcise the 10-byte commands and fixed
> format sense data.
More information about the T10