Eric Youngdale wrote:
>
> >Normally, I'd just go allocating my own buffer for this... but it occurs to
> >me that there has been much talk of changing the MAX_COMMAND_SIZE from 12
> >to 16 to support SCSI-III devices. A quick grep of drivers/scsi shows that
> >MAX_COMMAND_SIZE is only used to al
On Thu, Feb 15, 2001 at 04:40:35PM -0500, Eric Youngdale wrote:
> My preference is that 16-byte commands not even reach low-level drivers
> that are not prepared to deal with them. It would be a little more work to
> get it set up, but on the whole it would be safer, esp if we are considering
>Hrm... are you saying that they couldn't handle the larger buffer, or the
>larger command?
>
>If it's the larger command, that's fine with me. Just don't send that
>command. Just because we have the larger buffer doesn't mean that
>everything will support the larger commands. I hardly expect
On Thu, Feb 15, 2001 at 03:57:46PM -0500, Eric Youngdale wrote:
> It is a little more than just changing the define. I believe (and other
> people have confirmed) that some of the older host adapters would be unable
> to handle the larger command sizes. The limitations could be
> hardware/f
>Normally, I'd just go allocating my own buffer for this... but it occurs to
>me that there has been much talk of changing the MAX_COMMAND_SIZE from 12
>to 16 to support SCSI-III devices. A quick grep of drivers/scsi shows that
>MAX_COMMAND_SIZE is only used to allocate arrays and fill them with
Okay, this is partially political and partially technical. Linus, since
you're the final arbiter of these issues, your input is greatly
appreciated.
I'm working on integrating support for some USB Mass Storage devices.
Unfortunately, these devices are pretty much on the cutting edge, so they
use
6 matches
Mail list logo
