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 allocate arrays and fill them with 0, so
> >it _looks_ like just changing the #define in scsi.h to 16 will work
> >_just_fine_ with no other code modifications.
>
> Yes, for 2.4 I *think* I cleaned out all of the places where we had
> hardcoded "12" constants, and
> replaced them with MAX_COMMAND_SIZE, in preparation for this move.
>
> >The question is this: Could this actually happen for 2.4.2? We can solve
> >the technical problems, so the only thing to overcome is the "should we be
> >changing this in a 2.4.x kernel" question.
> >
> >There's been discussion in the past, which boiled down to "we'll do it when
> >we need it". And it looks easily doable. And we need it.
> >
> >Comments?
>
> 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/firmware in some cases. To be really safe, we probably want to
> limit 16-byte commands to host adapters that claim to be ready for them.
> Thus I believe that such a change would involve first adding a field for a
> maximum command size to the Scsi_Host structure, which gets initialized to
> 12 by default.
>
> The mid-layer would then need to reject attempts to queue commands
> longer than the established limit.
>
> Finally, hosts that are prepared to deal with 16-byte commands would
> need to change the maximum command length to 16.
>
> The changes aren't really all that hairy, assuming that I haven't missed
> anything. Anyone else have any comments?
Looking at changing MAX_COMMAND_SIZE from 12 to 16 from
a user space viewpoint:
- sg looks ok (both interfaces). Only the v3 interface
will allow 16 bytes commands through directly. [There
is an ioctl hack for the v2 interface.] Most important,
it won't break existing apps
- the SCSI_IOCTL_SEND_COMMAND ioctl(): no binary problem
but can't be used to pass 16 byte commands
- the CDROM_PACKET_COMMAND ioctl() exposes the maximum
command length in its interface struct with
unsigned char cmd[CDROM_PACKET_SIZE];
where CDROM_PACKET_SIZE is defined to be 12.
Jens, is it too late to up that define to 16? Otherwise that
ioctl() can't be used to pass 16 byte commands. While you
are at it, there is no way of specifying the command length
in that structure (that I can see). This would make it
difficult to pass through 16 byte or vendor specific
commands to the SCSI subsystem.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
