>rm... how about something like this:
>
>We add a field to the Scsi_Host structure which would indicate if they are
>SCSI-III able. By default, this field will be initialized to 0, indicating
>only 12-byte command readyness. The mid-level will reject cmd_len > 12
>unless this byte is != 0.
After reflection, my inclination is that the *correct* solution is to
fix the low-level drivers to reject the SCSI-III commands themselves. This
is more consistent with the devolution of authority from the mid-level to
the individual low-level drivers that has been going on. Unfortunately a
patch to implement this would be harder to implement. For 2.4, I would be
more tempted to go with what you describe above.
The infrastructure support for this is quite trivial. Add a bit to the
bitfield saying that the thing is SCSI-III capable, initialize it :-), and
add some minor logic to reject 16-byte commands to hosts that are not marked
as SCSI-III. For that matter, it would be possible (and cleaner) for the
generics driver to simply reject the things outright and not even attempt to
queue them in the first place...
I can work up the patches over the weekend, and send them out. I
haven't heard anyone raise any objections about either approach....
-Eric
>Short, sweet, and to the point. The question is, can we get it in more
>sooner than later? I'd really like to get all this integrated for a later
>2.4.x kernel.
----- Original Message -----
From: "Matthew Dharm" <[EMAIL PROTECTED]>
To: "Eric Youngdale" <[EMAIL PROTECTED]>
Cc: "Linux SCSI list" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, February 15, 2001 4:59 PM
Subject: Re: Changing MAX_COMMAND_SIZE within the 2.4.x timeframe?
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
