Matthew Wilcox wrote: > On Mon, May 22, 2006 at 07:54:35PM -0500, James Bottomley wrote: >> Actually, we've got another cockup here with drivers: some have set this >> to 8 or 16 and others to 7 or 15. If we apply this without auditing >> them, for those who set it to 7 or 15, the last target will end up >> inaccessible. > > So as scsi maintainer, what's your preference for the 'right way' to fix > this? Clearly a whole-scale driver audit is needed, so my preference is > to rename the variable (how about id_limit?) and then do a sweep > checking that everybody's using it correctly. > Ah. I see a pattern emerging. ncr53c7xx.c has this: #ifdef LINUX_1_2 || cmd->device->id > 7 #else || cmd->device->id > host->max_id #endif So appearently in the good old days max_id was indeed defined as the highest available target number. Whereas most 'modern' drivers define this c-style-wise as the first non-available number. So I would go for the latter approach and audit the drivers. Cheers, Hannes -- Dr. Hannes Reinecke hare@xxxxxxx SuSE Linux Products GmbH S390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de - : 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
