On Tue, 2012-07-17 at 11:28 +0200, Paolo Bonzini wrote: > Il 17/07/2012 11:11, James Bottomley ha scritto: > > We don't do stuff just because the standards allows it; just the > > opposite: we try to use the smallest implementations from the standards > > we can get away with just because the more things we do, the more > > exceptions and broken devices we come across. > > Yes, I realize failing only on specific sense codes as I did it in the > patch is not going to work. However, the other way round is not > problematic (explicitly allow some sense codes, fail on all others). Heh, I once thought that, but there's no end to the strange ideas USB manufacturers get. > Another example is "target operating conditions have changed". QEMU > cannot report such changes because scsi_error prints a warning (fine) > and then passes the unit attention upwards. With removable drives, this > has the same problem as resizing. Why would a removable device ever use any of the codes under this ASC when the medium hasn't changed? They're all for arrays (well except 0x10 and 0x11 ... and they're only supposed to apply to tape changers with autoload support declared in the control mode page). The unanswered point is still that there's no use case for a device that's both removable and requires array like sense code support. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
