Date: Thu, 8 Nov 2001 15:41:15 -0000 From: "Nick Hibma" <n_hibma@qubesoft.com> To: "Scott Long" <scott_long@btc.adaptec.com>, "Thomas Quinot" <quinot@inf.enst.fr> Cc: <freebsd-scsi@freebsd.org>, <freebsd-current@freebsd.org> Subject: RE: SCSI->IDE Message-ID: <CEEKLNFIGKODPCCPEKLDGEOLCDAA.n_hibma@qubesoft.com> In-Reply-To: <20011108081511.A81770@hollin.btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
How do you inform the upper layers that only 10+ byte commands are
allowed? (12 byte in the case of ATAPI).
Nick
> -----Original Message-----
> From: Scott Long [mailto:scott_long@btc.adaptec.com]
> Sent: 08 November 2001 15:15
> To: Thomas Quinot
> Cc: Nick Hibma; freebsd-scsi@freebsd.org; freebsd-current@freebsd.org
> Subject: Re: SCSI->IDE
>
>
> On Thu, Nov 08, 2001 at 10:42:43AM +0100, Thomas Quinot wrote:
> > Le 2001-11-07, Nick Hibma écrivait :
> >
> > > You are not doing any conversion of commands from SCSI to
> ATAPI. Did you
> > > verify that all SCSI commands are valid ATAPI commands?
> >
> > Actually the current version of the patch does do some translation
> > (MODE_{SENSE,SELECT}_6 are mapped to their _10 equivalent, because
> > the _6 variants are not implemented by ATAPI/MMC devices), but a
> > better solution might be to move these translations up to transport
> > independant layers, and be handled through quirk entries, or some
> > similar flagging mechanism. After all, ATAPI really is a /transport/
> > mechanism for SCSI commands: it is up to the initiator of a request
> > to know which command set to use for a given device.
>
> Adding even more quirk entries is not the right way to go. One, or
> both, of the following things should happen.
>
> 1. The SIM should inform the upper layers that 6 bytes commands are
> not allowed.
> 2. If a 6 byte command is issued and fails, the failure code
> should be
> analyzed and the command retried in its 10 byte version. If that
> succeeds, then the upper layers should be flagged to only use 10 byte
> commands.
>
> Scott
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CEEKLNFIGKODPCCPEKLDGEOLCDAA.n_hibma>