From mboxrd@z Thu Jan 1 00:00:00 1970 From: Badari Pulavarty Subject: Re: [patch for playing] Patch to support 4000 disks and maintain backward compatibility Date: Thu, 10 Apr 2003 18:09:55 -0700 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <200304101809.55311.pbadari@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: Received: from e35.co.us.ibm.com ([32.97.110.133]:10154 "EHLO e35.co.us.ibm.com") by vger.kernel.org with ESMTP id S264282AbTDKBAi convert rfc822-to-8bit (for ); Thu, 10 Apr 2003 21:00:38 -0400 In-Reply-To: List-Id: linux-scsi@vger.kernel.org To: Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org On Thursday 10 April 2003 04:53 pm, Andries.Brouwer@cwi.nl wrote: > From: Badari Pulavarty > > > I am more worried about names slipping. I atleast hope > > to see device names not changing by just doing > > rmmod/insmod. > > > > But you see, the present sd_index_bits[] gives no such > > guarantee. In sd_detach a bit is cleared, in sd_attach > > the first free bit is given out. There is no memory. > > But the disks are probed in the same manner as last time > (if the disks/controllers are not moved, crashed etc..). > So we will end up getting same names. > > Oh, but if next_index is 0 in the module (or reset by the > init_module code), then also with index = next_index++ > things will be the same after rmmod/insmod. Here is my problem.. #insmod ips.o < found 10 disks> #insmod qla2300.o < found 10 disks> #rmmod ips.o #insmod ips.o - Badari