On Thu, 2009-04-23 at 11:25 -0600, Matthew Wilcox wrote: > On Thu, Apr 23, 2009 at 10:39:41AM -0400, Jeff Garzik wrote: > > Matthew Wilcox wrote: > > >On Thu, Apr 23, 2009 at 02:10:13PM +0000, James Bottomley wrote: > > >>I'm with Jeff on this one. We had an identically similar problem with > > >>REPORT LUNS, which, today is the basis of SCSI discovery. > > > > > >Yes, REPORT LUNS is quite essential. > > > > > >It's not exactly in the same category as reporting device form factor > > >and rotational speed. If REPORT LUNS is wrong, we're in really deep > > >trouble. If device form factr is wrong ... umm ... nothing much happens. > > >If rotational speed is wrong, we might have a suboptimal IO pattern. > > > > If the general attitude is "oh, that info might be wrong", why will app > > developers bother at all? > > Any info might be wrong. SCSI drives might return the wrong thing in > EVPD b1 too. We don't check that in the kernel, we just return it to > user space. Right, that's the REPORT LUNs case: If you report compliance to a standard that doesn't have it, we don't use it *unless* you have an inquiry data whitelist to say we should. If you report compliance to a standard that does, then we lead with REPORT LUNs *unless* you're in a blacklist of people who don't implement correctly. The point is that we use the gross standard compliance data to flip how we treat the device. So we're chasing the case where what we're doing is most likely to work and then we fix up the corner problems in each of the cases. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
