Re: camcontrol(8) and MODE_[SENSE|SELECT]_10

On Wed, Oct 06, 2004 at 02:51:21 -0700, Bruce M Simpson wrote:
> I need some advice regarding the handling of 10-byte MODE SENSE/SELECT.
> 
> Apologies if this is more appropriate for freebsd-scsi_at_ to which I am
> not currently subscribed.

Yes, freebsd-scsi would probably be more appropriate.

> Here is the patch I used to hack camcontrol to force the use of
> MODE_SENSE_10 and MODE_SELECT_10 for UFI (umass) devices, i.e.
> USB floppy drives.
> 
> This is probably not the cleanest way but it avoids using a global flag
> for such a thing, which might be cleaner.
> 
> Note however that the mode page layouts in src/share/misc/scsi_modes
> only seem to be correct for the 6-byte MODE_SENSE and MODE_SELECT
> which are not supported for such devices; for 10-byte forms the
> mode page layout seems to be subtly different.

As you noted in your followup mail, it's actually the mode page headers
that are different lengths.

In theory the mode page layouts in the scsi_modes file should be correct
for 6 or 10 byte commands.

> Could someone more knowledgeable about the inner workings of CAM and
> SCSI in FreeBSD than I advise how we could go about teaching camcontrol(8)
> to fetch and display mode pages in a human-readable manner?
> (i.e. without necessarily implementing a new utility right away)

Conceptually, I'd rather specify a minimum CDB size rather than a "force 10
byte" flag.  That's especially true if we end up doing a global flag.  That
would go along with the idea in the scsi_mode_{sense,select}_len() and
scsi_read_write() functions of having a minimum command size.

e.g., with a read or a write, the user might specify a minimum command size
of 10, but would actually need a 16 byte CDB to handle the lba or length
they requested.

Right now, mode sense/select are the only commands directly supported by
camcontrol(8) that have different length CDBs.  It might make sense to do a
flag that would work for more than one command, though, to support
something like read capacity or sync cache as well as mode sense and mode
select.

Let me think on it a bit and see what I can come up with.  For now, folks
can use your patch to deal with devices like this.

> This is necessary in order to extract the geometry for a USB floppy
> drive in order that track-by-track format may be implemented; the
> FORMAT UNIT command for USB floppy drives requires such behaviour
> as per the UFI Specification (usbmass-ufi10.pdf).

Ken
-- 
Kenneth Merry
ken_at_FreeBSD.ORG