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
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
