On Tue, Jan 08, 2008 at 06:56:11PM +0100, Stefan Richter wrote: > It's hald or something like that. Can't we get hald to look at the cached results of the inquiry command, handily available through sysfs? > Matthew Wilcox wrote: > > I have a hard time thinking this needs to be handled generically > > because READ CAPACITY isn't in the Primary Command Set, unlike INQUIRY. > > It's mandatory for SBC devices to implement it, but other devices > > shouldn't even implement it. > > It is also mandatory in RBC, which most SBP-2 to IDE or SBP-2 to SATA > bridges implement (besides MMC, if a CD/DVD-ROM/R/W is attached). According to SPC4r05a, READ CAPACITY(10) (opcode 25) is Mandatory for D, W and O. READ CAPACITY (opcode 25) is Optional for R. READ CARD CAPACITY (also opcode 25) is Mandatory for K. D - DIRECT ACCESS BLOCK DEVICE (SBC-3) W - WRITE ONCE BLOCK DEVICE (SBC) O - OPTICAL MEMORY BLOCK DEVICE (SBC) R - CD/DVD DEVICE (MMC-6) K - OPTICAL CARD READER/WRITER DEVICE (OCRW) According to this table (D.2 for anyone following along at home), RBC devices are not supposed to implement it. > I would not at all like to see a respective workaround added to the sbp2 > driver. Sbp2 is a transport layer which does not touch commands. Maybe > an in-kernel workaround would be considered by whoever maintains the > point where that extra INQUIRY is injected (via sd or sg, I don't know > which). It would be thoroughly inappropriate to put this workaround in the midlayer. sbp2 isn't a good place either, but it's better than sg/sd/scsi_ioctl/... -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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
