Submissions for 2.4.19-pre [sdmany (Richard Gooch)] [Discuss :) ]
Subsystems (5)
This is the second of several mails containing patches to be included in 2.4.19. Some are worthy of dicussion prior to inclusion and have been marked as such. The majority of these patches were found on lkml; the remaining ones have URLs listed.
This one was both on lkml and ftp://ftp.XX.kernel.org/pub/linux/kernel/people/rgooch/v2.4/sdmany-patch-v3.bz2
I have attached this patch because I have rediffed it to apply nicely to 2.4.19-pre1.
------
Michael Cohen
OhDarn.net
Documentation/Configure.help +11 -0
@@ -6667,6 +6667,17 @@ is located on a SCSI disk. In this case, do not compile the driver for your SCSI host adapter (below) as a module either. +Many SCSI Discs support +CONFIG_SD_MANY + This allows you to support a very large number of SCSI discs + (approximately 2080). You will also need to set CONFIG_DEVFS_FS=y + later. This option may consume all unassigned block majors + (i.e. those which do not have an allocation in + Documentation/devices.txt). Enabling this will consume a few extra + kilobytes of kernel memory. + + Unless you have a large storage array, say N. + Maximum number of SCSI disks that can be loaded as modules CONFIG_SD_EXTRA_DEVS This controls the amount of additional space allocated in tables for
drivers/scsi/Config.in +2 -1
@@ -3,7 +3,8 @@ dep_tristate ' SCSI disk support' CONFIG_BLK_DEV_SD $CONFIG_SCSI if [ "$CONFIG_BLK_DEV_SD" != "n" ]; then - int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 + bool ' Many (~2080) SCSI discs support (requires devfs)' CONFIG_SD_MANY + int ' Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI
drivers/scsi/hosts.h +2 -3
@@ -506,9 +506,8 @@const char * tag;struct module * module;/* Used for loadable modules */ unsigned char scsi_type; -unsigned int major; -unsigned int min_major;/* Minimum major in range. */ -unsigned int max_major;/* Maximum major in range. */ +unsigned int *majors;/* Array of majors used by driver */ +unsigned int num_majors;/* Number of majors used by driver */ unsigned int nr_dev;/* Number currently attached */ unsigned int dev_noticed;/* Number of devices detected. */ unsigned int dev_max;/* Current size of arrays */
drivers/scsi/osst.c +0 -1
@@ -162,7 +162,6 @@ name: "OnStream tape", tag: "osst", scsi_type: TYPE_TAPE, - major: OSST_MAJOR, detect: osst_detect, init: osst_init, attach: osst_attach,
drivers/scsi/scsi_lib.c +6 -19
@@ -795,25 +795,12 @@* Search for a block device driver that supports this * major. */ -if (spnt->blk && spnt->major == major) { -return spnt; - } -/* -* I am still not entirely satisfied with this solution, -* but it is good enough for now. Disks have a number of -* major numbers associated with them, the primary -* 8, which we test above, and a secondary range of 7 -* different consecutive major numbers. If this ever -* becomes insufficient, then we could add another function -* to the structure, and generalize this completely. -*/ -if ( spnt->min_major !=0 - && spnt->max_major !=0 - && major >= spnt->min_major - && major <= spnt->max_major ) - { -return spnt; - } +int i; +if (!spnt->blk || !spnt->majors) +continue ; +for (i =0 ; i < spnt->num_majors; ++i) +if (spnt->majors[i] == major) +return spnt; }return NULL ; }
drivers/scsi/sd.c +92 -29
226 lines not on this page · raw message
drivers/scsi/sd.h +6 -2
@@ -42,10 +42,14 @@*/ extern kdev_t sd_find_target (void *host,int tgt); -#define N_SD_MAJORS 8 +#define N_SD_PREASSIGNED_MAJORS 8 -#define SD_MAJOR_MASK (N_SD_MAJORS - 1) +#ifdef CONFIG_SD_MANY +#define SD_PARTITION (i) ((sd_devnum_to_index((i)) << 4) | ((i)&0x0f)) +#else +#define SD_MAJOR_MASK (N_SD_PREASSIGNED_MAJORS - 1)#define SD_PARTITION (i) (((MAJOR(i) & SD_MAJOR_MASK) << 8) | (MINOR(i) & 255)) +#endif #endif
drivers/scsi/sg.c +0 -1
@@ -125,7 +125,6 @@ { tag:"sg", scsi_type:0xff, - major:SCSI_GENERIC_MAJOR, detect:sg_detect, init:sg_init, finish:sg_finish,
drivers/scsi/sr.c +4 -1
@@ -69,12 +69,15 @@static int sr_init_command (Scsi_Cmnd *); +static unsigned int sr_major =SCSI_CDROM_MAJOR ; +static struct Scsi_Device_Template sr_template = { name:"cdrom" , tag:"sr" , scsi_type:TYPE_ROM , - major:SCSI_CDROM_MAJOR , + majors:&sr_major, + num_majors:1 , blk:1 , detect:sr_detect, init:sr_init,
drivers/scsi/st.c +0 -1
@@ -170,7 +170,6 @@ name:"tape", tag:"st", scsi_type:TYPE_TAPE, - major:SCSI_TAPE_MAJOR, detect:st_detect, init:st_init, attach:st_attach,
include/linux/blk.h +4 -0
@@ -146,7 +146,11 @@#define DEVICE_NAME "scsidisk"#define TIMEOUT_VALUE (2*HZ) +#ifdef CONFIG_SD_MANY +#define DEVICE_NR (device) sd_devnum_to_index((device)) +#else #define DEVICE_NR (device) (((MAJOR(device) & SD_MAJOR_MASK) << (8 - 4)) + (MINOR(device) >> 4)) +#endif /* Kludge to use the same number for both char and block major numbers */ #elif (MAJOR_NR ==MD_MAJOR ) && defined(MD_DRIVER )
Documentation/Configure.help line 6674
Quoted 4 lines
Documentation/Configure.help +4
-0+CONFIG_SD_MANY + This allows you to support a very large number of SCSI discs + (approximately 2080). You will also need to set CONFIG_DEVFS_FS=y + later. This option may consume all unassigned block majors
As discussed before - this is a bad idea. Please don't regurgitate random incorrect patches - it doesnt help. For 2.4 there is no clean way to do this for 2.5 driverfs and a 32bit dev_t gets you there for free and done right
Quoted 9 lines · Alan Cox
Documentation/Configure.help line 6674
Quoted 4 lines
Documentation/Configure.help +4
-0+CONFIG_SD_MANY + This allows you to support a very large number of SCSI discs + (approximately 2080). You will also need to set CONFIG_DEVFS_FS=y + later. This option may consume all unassigned block majorsAs discussed before - this is a bad idea. Please don't regurgitate random incorrect patches - it doesnt help. For 2.4 there is no clean way to do this for 2.5 driverfs and a 32bit
dev_tgets you there for free and done right
No, Alan. *You* don't think this is a good idea. Not everyone agrees with you. My patch is safe: it makes use of the safe major allocation function so that >128 SD's can be used. You seem to be against this patch because it would mean that you can't just keep handing out major numbers, ignoring Linus' "no new majors" decree.
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 3 lines
function so that >128 SD's can be used. You seem to be against this patch because it would mean that you can't just keep handing out major numbers, ignoring Linus' "no new majors" decree.
Linus no new numbers decree was irrelevant. You can live in your little ivory tower if it makes you happy, but everyone else works off the post Linus devices.txt maintained by LANANA.
Even if your hack reflected the newer table it would still be an ugly hack for a few special case situations rather than any notion of release quality. Its a very clever devfs hack, but its still an ugly hack
Do it right, and do it in 2.5
Alan
Quoted 5 lines · Alan Cox
Even if your hack reflected the newer table it would still be an ugly hack for a few special case situations rather than any notion of release quality. Its a very clever devfs hack, but its still an ugly hack
Do it right, and do it in 2.5
Hate to say it but 2.5 is not ready for any kind of production use, and some people really need to connect more SCSI devices than are currently supported. That's NOT ivory tower, it's real world "do it with Linux" problem solving.
If you have a "do it right" solution which is stable, for a stable kernel, please let us know. This isn't a theoretical problem.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 4 lines
Hate to say it but 2.5 is not ready for any kind of production use, and some people really need to connect more SCSI devices than are currently supported. That's NOT ivory tower, it's real world "do it with Linux" problem solving.
I'd be interested to know if Al Viro considers devfs production use ready yet
Quoted 6 lines · Alan Cox
Quoted 4 lines
Hate to say it but 2.5 is not ready for any kind of production use, and some people really need to connect more SCSI devices than are currently supported. That's NOT ivory tower, it's real world "do it with Linux" problem solving.
I'd be interested to know if Al Viro considers devfs production use ready yet
I would say that is a fair question. I find it in the production kernel? Good, so it was considered ready by someone. Seems to me one of the Redhat kernels had devfs as a module, they seem to think so.
It's a good question, though, and I am assuming that the answer is "it's in the stable kernel" which isn't yes or no.
If it's not stable then there simply is no Linux solution to large storage. Given what vendors are doing I find that unintuitive.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 3 lines
I would say that is a fair question. I find it in the production kernel? Good, so it was considered ready by someone. Seems to me one of the Redhat kernels had devfs as a module, they seem to think so.
<Red Hat on>We don't ship devfs.</Red Hat>
Alan
Quoted 5 lines · Alan Cox
Quoted 3 lines
I would say that is a fair question. I find it in the production kernel? Good, so it was considered ready by someone. Seems to me one of the Redhat kernels had devfs as a module, they seem to think so.
<Red Hat on>We don't ship devfs.</Red Hat>
Thanks, someone has obviously rebuilt the kernel on the machine I was considering, possibly even me... :-(
In any case if devfs is stable enough to be in the stable kernel, can we really say that something using it isn't (for that reason alone)? I any case I'm still interested, TB are not what they used to be.
Okay, I'll look at other solutions, AIX seems able to handle it.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.