Hannes Reinecke wrote:
> 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.
> 
Wasn't too bad actually. Only some very old drivers did it wrong.
I don't think we'd need to redo everything by renaming variables.
Some fixing will be sufficient (see attached patch).

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux Products GmbH		S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de