Quirk for this?

[Scott Long]

Warner Losh wrote:
>> I understand what you're saying.  If you look in the umass driver, there
>> is already a mechanism for quirks as well as a fairly large collection
>> of quirks for bad SCSI protocol behavior from devices.  These should all
>> move up to CAM, I agree.  However, what exists in CAM right now for
>> XPORT-specific support is just a series of 'if' statements scattered
>> around cam_xpt.c.  If you moved Warner's quirk up as well as the other
>> umass quirks, you're going to quickly make a royal mess out of
>> cam_xpt.c.  That's what I want to avoid.  Once we figure out exactly
>> what we want out of the XPORT code and get it a little more defined and
>> organized, I think we can then start moving the quirks out of the umass
>> driver.  Until then, solving Warner's problem via umass.c is easy and
>> doesn't complicate the end goal much at all.
> 
> I would think that the quriks in the umass driver would be
> communicated in a transport neutral way to cam_xpt.c and friends.  ANY
> transport could set ANY quirk and the code would just cope.  No need
> for the xpt layer to peer into the transport at all (or is that the
> 'sim' in CAMese).
> 

This is what I had in mind.  Where the quirks come from is fairly 
arbitrary, but the code to execute the quirks will someday live in
the XPT or periph drivers, not the SIM.

> For the moment, hacking umass is easiest and when the more generic
> mechanism comes along, the minor hack that I'm putting in wouldn't be
> burdonsome.

Yes, and consistent with how it's done now.

Scott