public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Badari Pulavarty <pbadari@us.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Joel.Becker@oracle.com, <linux-kernel@vger.kernel.org>
Subject: Re: 64-bit kdev_t - just for playing
Date: Wed, 2 Apr 2003 09:31:38 -0800	[thread overview]
Message-ID: <200304020931.38671.pbadari@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304021413210.12110-100000@serv>

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

On Wednesday 02 April 2003 04:18 am, Roman Zippel wrote:
> Hi,
>
> On Mon, 31 Mar 2003, Badari Pulavarty wrote:
> > I have been playing with supporting 4000 disks on IA32 machines.
> > There are bunch of issues we need to resolve before we could
> > do that.
> >
> > I am using scsi_debug to simulate 4000 disks. (Ofcourse, I had
> > to hack "sd" to support more than 256 disks).
>
> Could you please post your changes to sd.c and anything relevant to it?
> Thanks.
>
> bye, Roman

Roman,

Here is the patch for sd to allow more than 256 disks.
There are few issues with the patch that need to be resolved.

1) With the patch I get 16 bits for minor. Since 4 bits are used for
partition, we get 12 bits to represent disks. So each major can support
2^12 = 4096 disks. Disks 0 - 4095 are mapped to major=8, 
disks 4096 - 8191 to major = 65 and so on..

This means ..

(i) I need to create nodes in /dev/ to match new <major, minor> for 
these disks.  Currently "mknod" is broken due to glibc issues with dev_t.

(ii) We need to worry about backward compatibility. For example:
17th disk used to have <65, 0>. Now its major, minor is <8, 256>.
So /dev/ entires need to be re-created to match these, everytime
you reboot 2.4/2.5 etc. Greg KH udev might fix this for us. 

2) Do we still need 16 majors for disks ?

We could change my patch to work around major/minor assignment
issues and maintain backward compatibility. 

Thanks,
Badari




[-- Attachment #2: sd.patch --]
[-- Type: text/x-diff, Size: 1353 bytes --]

--- linux/drivers/scsi/sd.c	Thu Mar 20 15:06:00 2003
+++ linux.new/drivers/scsi/sd.c	Fri Mar 21 11:50:54 2003
@@ -56,7 +56,9 @@
  * Remaining dev_t-handling stuff
  */
 #define SD_MAJORS	16
-#define SD_DISKS	(SD_MAJORS << 4)
+#define SD_DISKS_PER_MAJOR_SHIFT	(KDEV_MINOR_BITS - 4)
+#define SD_DISKS_PER_MAJOR	(1 << SD_DISKS_PER_MAJOR_SHIFT)
+#define SD_DISKS	(SD_MAJORS << SD_DISKS_PER_MAJOR_SHIFT)
 
 /*
  * Time out in seconds for disks and Magneto-opticals (which are slower).
@@ -1328,17 +1330,23 @@ static int sd_attach(struct scsi_device 
 	sdkp->index = index;
 
 	gd->de = sdp->de;
-	gd->major = sd_major(index >> 4);
-	gd->first_minor = (index & 15) << 4;
+	gd->major = sd_major(index >> SD_DISKS_PER_MAJOR_SHIFT);
+	gd->first_minor = (index & (SD_DISKS_PER_MAJOR - 1)) << 4;
 	gd->minors = 16;
 	gd->fops = &sd_fops;
 
-	if (index >= 26) {
+	if (index < 26) {
+		sprintf(gd->disk_name, "sd%c", 'a' + index % 26);
+	} else if (index < (26*27)) {
 		sprintf(gd->disk_name, "sd%c%c",
 			'a' + index/26-1,'a' + index % 26);
 	} else {
-		sprintf(gd->disk_name, "sd%c", 'a' + index % 26);
-	}
+		const unsigned int m1 = (index/ 26 - 1) / 26 - 1;
+		const unsigned int m2 = (index / 26 - 1) % 26;
+		const unsigned int m3 = index % 26;
+		sprintf(gd->disk_name, "sd%c%c%c", 
+			'a' + m1, 'a' + m2, 'a' + m3);
+	}	
 
 	sd_init_onedisk(sdkp, gd);
 

  reply	other threads:[~2003-04-02 17:22 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-31 23:41 64-bit kdev_t - just for playing Badari Pulavarty
2003-03-31 23:54 ` William Lee Irwin III
2003-03-31 23:55 ` Joel Becker
2003-04-02 12:18 ` Roman Zippel
2003-04-02 17:31   ` Badari Pulavarty [this message]
2003-04-02 22:03     ` H. Peter Anvin
2003-04-03 10:09       ` David Lang
2003-04-03 11:14         ` Lars Marowsky-Bree
2003-04-03 12:13     ` Roman Zippel
2003-04-03 13:37       ` Andries Brouwer
2003-04-03 14:01         ` Roman Zippel
2003-04-07 15:02           ` H. Peter Anvin
2003-04-07 20:10             ` Roman Zippel
2003-04-07 21:57               ` Roman Zippel
2003-04-07 22:43                 ` Kevin P. Fleming
2003-04-08 15:22                   ` Roman Zippel
2003-04-08 22:53                 ` Werner Almesberger
2003-04-08 23:11                   ` David Lang
2003-04-08 23:47                     ` Werner Almesberger
2003-04-08 23:58                       ` Kevin P. Fleming
2003-04-08 23:56                     ` H. Peter Anvin
2003-04-08 23:06                       ` Andrew Morton
2003-04-09  0:40                       ` Roman Zippel
2003-04-09  1:02                         ` Joel Becker
2003-04-09  1:25                           ` Roman Zippel
2003-04-09 16:42                       ` Roman Zippel
2003-04-09  0:21                   ` Roman Zippel
2003-04-11  9:58               ` Pavel Machek
2003-04-08 15:29             ` Roman Zippel
  -- strict thread matches above, loose matches on Subject: below --
2003-04-09 18:40 James Bottomley
2003-04-09 20:54 ` Roman Zippel
2003-04-10  2:19   ` James Bottomley
2003-04-10 12:47     ` Roman Zippel
2003-04-10 15:30       ` James Bottomley
2003-04-10 23:53         ` Roman Zippel
2003-04-11  0:01           ` David Lang
2003-04-11  0:17             ` Roman Zippel
2003-04-11  0:47           ` Joel Becker
2003-04-11  1:11             ` Roman Zippel
2003-04-09 18:36 Andries.Brouwer
2003-04-09 21:11 ` Roman Zippel
2003-04-01 18:32 Andries.Brouwer
2003-03-28 15:33 Andries.Brouwer
2003-03-28 15:49 ` Roman Zippel
2003-03-28 11:46 Andries.Brouwer
2003-03-28 11:57 ` Roman Zippel
2003-03-28 11:10 Andries.Brouwer
2003-03-28 11:36 ` Roman Zippel
2003-03-30 20:05   ` H. Peter Anvin
2003-03-30 20:13     ` Roman Zippel
2003-03-27 22:37 Andries.Brouwer
2003-03-27 22:55 ` Roman Zippel
2003-03-27 20:27 Andries.Brouwer
2003-03-27 22:12 ` Roman Zippel
2003-03-27 22:55   ` Alan Cox
2003-03-27 23:19     ` Roman Zippel
2003-03-27 23:48       ` Greg KH
2003-03-28  9:47         ` Roman Zippel
2003-03-28 18:05           ` Joel Becker
2003-03-28 18:48             ` Roman Zippel
2003-03-31  8:31               ` bert hubert
2003-03-31  8:52                 ` Roman Zippel
2003-03-31 17:24                   ` Joel Becker
2003-03-31 21:32                     ` Roman Zippel
2003-03-31 22:18                       ` Alan Cox
2003-03-31 23:42                         ` Roman Zippel
2003-04-01 14:42                           ` Alan Cox
2003-04-01 16:35                             ` Greg KH
2003-04-02 13:02                               ` Roman Zippel
2003-04-01 14:42                           ` Alan Cox
2003-04-01 16:52                             ` Christoph Hellwig
2003-04-01 21:59                             ` H. Peter Anvin
2003-04-02  7:12                               ` Christoph Hellwig
2003-04-02  7:22                                 ` H. Peter Anvin
2003-03-31 23:45                         ` Joel Becker
2003-03-31 23:07                       ` Joel Becker
2003-03-31 23:35                         ` Roman Zippel
2003-03-27  1:09 Andries.Brouwer
2003-03-27 19:23 ` Roman Zippel
2003-03-30 20:10 ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200304020931.38671.pbadari@us.ibm.com \
    --to=pbadari@us.ibm.com \
    --cc=Joel.Becker@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox