Eric Youngdale wrote:
> 
>     All of this talk about 10 vs 6 byte commands reminds me of another
> related issue.  16 byte commands...
> 
>   The most recent patches that I sent off to Linus clean up a number of the
> issues related to the possibility of sending 16-byte commands.  Note that
> the definition of MAX_COMMAND_SIZE is still 12 in scsi.h - it is just that I
> fixed a lot of the hardcoded "12" constants that were lying around in the
> mid-layer - this means that if you were to change it to 16, it is more
> likely that things would work, at least as far as the mid-level is
> concerned, but there are still no guarantees.
> 
>     Raising this to 16 still presents some interesting challenges.  I am not
> at all convinced that all of the low-level drivers are up to the task.  Some
> of them may even have hardware limitations that would prevent 16-byte
> commands from ever being correctly issued.  The wd7000 driver comes to
> mind - it *appears* that the mailbox definition that the host adapter uses
> effectively limits you to 12 byte commands, and the mailbox structure
> definition fixed in hardware.  At this point I have no idea which of the
> other drivers are ready to accept longer commands and which would not.  A
> simple grep of all of our low-level drivers show *potential* problems with
> 22 of the low-level drivers.
> 
>     53c7,8xx 53c7xx FlashPoint advansys eata eata_dma_proc eata_generic
>     gdth i91uscsi ibmmca ide-scsi ini9100u ips pluto psi240i qlogicisp
> qlogicpti
>     sym53c8xx tmscsim u14-34f ultrastor wd7000
> 
> This list is essentially just the drivers that have a hardcoded [12]
> somewhere in them.  Some of the drivers may well have other limitations that
> this crude approach couldn't pick up.  Some of the [12] constants in there
> may be completely innocent, of course - I cannot easily tell.  Further
> complicating matters is that I would venture a guess that some drivers not
> prepared to deal with 16-byte commands are going to silently corrupt memory
> in some evil way.
> 
>     The hacker way of approaching this is to simply bump the number and see
> what breaks.  A more responsible way of approaching this would be to set a
> maximum command length in the host template, and set a default of 12.  We
> would essentially have to prove in all of the low-level drivers with 16-byte
> commands and change the setting as we verify correct functioning.  Given the
> large numbers of low-level drivers with potential problems, I am actually
> leaning with the more conservative approach - this would put the onus on
> low-level driver maintainers to figure out what if anything they need to do,
> and then bump the limit in the Scsi_Host structure.
> 
>     At the moment, I don't feel a need to rush into anything - I have more
> important things to focus on right now.  The cleanups that I already did
> were motivated by the annoyance of seeing hardcoded [12] values sprinkled
> throughout the mid-layer.  Right now I just wanted to toss the ideas out and
> see if people have comments.

Eric,
I concur with your conservative approach to this matter. "Does Linux
handle 16 byte commands?" is a question I get asked periodically.
Someone posted a patch on this newsgroup but I suspect it has
only been tested on one low level adapter. I examined this patch
and then did a grep for "12" in the drivers/scsi directory and
came up with way too many hits ...

As for the scsi generic driver, it can handle 16 byte commands (in
a rather awkward way using the SG_NEXT_CMD_LEN ioctl()) in
kernels >= lk 2.2.10 . The version 3 sg driver can handle 16 byte
commands in a much more straight forward way (i.e. pointer to command
and associated length). It seems as though the version 3 sg driver
is not going to be accepted into the 2.3 development tree (it has
already been presented several times).

Some tricks would be needed to get a 16 byte commands through the
SCSI_IOCTL_SEND_COMMAND ioctl() interface. It is not obvious to me
how this could be done without potentially breaking some existing
applications that use this ioctl.

Do the other "high level" scsi drivers (sd, st or sr) have any
requirement for 16 byte commands?

Doug Gilbert

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to