Date: Thu, 22 Aug 2002 22:53:27 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Thomas Quinot <thomas@cuivre.fr.eu.org> Cc: Nate Lawson <nate@root.org>, scsi@FreeBSD.ORG Subject: Re: CDB6/10 negotiation Message-ID: <20020822225327.B13285@panzer.kdm.org> In-Reply-To: <20020821230409.C66733@melusine.cuivre.fr.eu.org>; from thomas@cuivre.fr.eu.org on Wed, Aug 21, 2002 at 11:04:09PM %2B0200 References: <Pine.BSF.4.21.0208211327510.57170-100000@root.org> <20020821230409.C66733@melusine.cuivre.fr.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 21, 2002 at 23:04:09 +0200, Thomas Quinot wrote: > Le 2002-08-21, Nate Lawson écrivait : > > > Consensus is suggesting the best approach is to put USB transport checks > > under CAM_NEW_TRAN_CODE in cam_xpt.c and then use them to set > > device-specific behavior. > > I think we should keep a clean separation between transport and > protocol. Available command sets should not be tied to the protocol they > are used on. For example the fact that an ATAPI CD-ROM drive is accessed > through the ATAPI transport and the fact that it implements the MMC-2 > command set should be recorded separately. With the new transport code, we've made a distinction between transport and protocol. e.g., some of the defined protocols at the moment are SCSI, ATA, and ATAPI. Since SCSI and ATAPI are very similar, all we really need to do is make sure we use commands that are supported on ATAPI when we're talking to an ATAPI protocol device. (The transport could be ATA, USB, etc.) ATA is different, and will likely require more changes to support it via CAM. > > removed. The quirks that remain will truly be quirks where a device > > reports capabilities it doesn't really support. > > Some devices can also require quirks for maximum I/O operation size > (specifically, ZIP drives need a quirk in scsi_da to be able to use > FFS). Cf. the scsi_da.c part in > http://www.cuivre.fr.eu.org/~thomas/atapicam/patches/atapicam-20020409.diff > (which needs to be adapted for -CURRENT.) It's unfortunate that they've got limitations like that. Does anyone know whether the same is true of the SCSI version? (I'm kinda curious.) This isn't the same thing, but Justin and I have been planning for a while to implement a facility to report up to the upper layers information on restrictions on I/O sizes for individual drivers. e.g., driver X can transfer no more than 64K or 128K at a time. This would allow us to get rid of the current DFLTPHYS limitation for the pass(4) driver, and potentially all limitations if we go to a more flexible buffer implementation. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020822225327.B13285>