Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 08 Feb 2002 10:31:08 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        =?iso-8859-1?Q?G=E9rard?= Roudier <groudier@free.fr>
Cc:        Josef Karthauser <joe@tao.org.uk>, "Eugene M. Kim" <gene@nttmcl.com>, Oliver Fromme <olli@secnetix.de>, FreeBSD Hardware Mailing List <hardware@FreeBSD.ORG>, FreeBSD Hackers Mailing List <hackers@FreeBSD.ORG>
Subject:   Re: USB "Memorybird" quirks
Message-ID:  <3C64196C.CC0318FD@mindspring.com>
References:  <20020207193911.U1513-100000@gerard>

next in thread | previous in thread | raw e-mail | index | archive | help
G=E9rard Roudier wrote:
> A couple of READ/WRITE 6 byte commands are still mandatory for SCSI blo=
ck
> devices in order to accomodate softwares as boot software for example t=
hat
> may not be upgradable on systems still in use.

Not a real problem, since if the device doesn't support
the 5 byte commands, it's not booting with the legacy
system software anyway, since you can't boot legacy stuff
on it.


> Softwares that are
> maintained should no longer use 6 byte commands, but use the 10 byte
> commands replacement (for years...).

This I don't understand.  FreeBSD appears to have a
preference for the 6 byte commands in the drivers,
which are only used after boot.

Further, it makes sense that you'd prefer 6 byte if
you could, since it makes your commands 60% smaller,
which should make them faster.


> So, unless we want to accomodate applications that still may send 6 byt=
e
> commands through passthrough driver, no translator should be needed. Ju=
st
> make class drivers use 10 byte commands instead.

There has to be a reason that FreeBSD has a preference
for 6 bytes in the CAM code... ?!?


> OTOH, using 6 byte READ/WRITE commands is very restrictive if we ever w=
ant
> to implemement kind of trustable disk write caching support since they =
do
> not allow to selectively force media access (this is achieved by the FU=
A
> bit in >=3D 10 byte READ/WRITE command).
> =

> As a result, no device should be quirked nowadays as failing READ/WRITE=
 6
> byte commands. Just maintained softwares should get rid of those comman=
ds
> asap.

It sounds like devices that only support 6 byte commands
are the ones that need quirked?

In other words, you're just reversing the default and
the fallback positions.

I think auto-detecting the quirk is still a good bet,
even in the 6 byte only case, just as it would have
been in the 10 byte only case.

Thanks for the info on what's supposed to be done going
forward, though.  If there's no performance issue with
10 byte commands, inverting the default and the quirk
handling in the failure case seems to be the right thing
to do.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C64196C.CC0318FD>