From owner-freebsd-hackers Fri Feb 8 10:38:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 1489637B419; Fri, 8 Feb 2002 10:38:05 -0800 (PST) Received: from pool0031.cvx22-bradley.dialup.earthlink.net ([209.179.198.31] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16ZFu6-0005UD-00; Fri, 08 Feb 2002 10:37:48 -0800 Message-ID: <3C64196C.CC0318FD@mindspring.com> Date: Fri, 08 Feb 2002 10:31:08 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?G=E9rard?= Roudier Cc: Josef Karthauser , "Eugene M. Kim" , Oliver Fromme , FreeBSD Hardware Mailing List , FreeBSD Hackers Mailing List Subject: Re: USB "Memorybird" quirks References: <20020207193911.U1513-100000@gerard> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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