Hi Marcelo,
here comes patch 3/5 from a series of patches to support more than 128 (and
optionally more than 256) SCSI disks with Linux 2.4 by changing the sd driver
to dynamically allocate memory and register block majors as disks get
attached.
The patches are all available at
http://www.suse.de/~garloff/linux/scsi-many/
Patch 3 does use the infrastructure of patch 1 to allow specifying the
root filesystem as a kernel parameter using devfs syntax (e.g.
root=/dev/scsi/c2b0t9u0p5), but also working on non-devfs systems.
Together with the (already existing) scsihosts= parameter, this can
be quite useful if you have many SCSI disks with changing configurations.
This patch is against 2.4.19rc1. It depends on 1/3.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
Hi Kurt,
one little thing:
In the third "if" statement in scsiname_to_kdev_t you search for "scd" but
set tp to "sr".
That should also be "scd" I'd guess.
Cheers,
Aron
Hi Marcelo,
here comes patch 3/5 from a series of patches to support more than 128 (and
optionally more than 256) SCSI disks with Linux 2.4 by changing the sd
driver
to dynamically allocate memory and register block majors as disks get
attached.
The patches are all available at
http://www.suse.de/~garloff/linux/scsi-many/
Patch 3 does use the infrastructure of patch 1 to allow specifying the
root filesystem as a kernel parameter using devfs syntax (e.g.
root=/dev/scsi/c2b0t9u0p5), but also working on non-devfs systems.
Together with the (already existing) scsihosts= parameter, this can
be quite useful if you have many SCSI disks with changing configurations.
This patch is against 2.4.19rc1. It depends on 1/3.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
(See attached file: scsi-boot-scsi-2419rc1.diff)(See attached file:
attbncke.dat)
Hi Aron,
On Mon, Jul 29, 2002 at 09:22:40AM +0200, Aron Zeh wrote:
> one little thing:
> In the third "if" statement in scsiname_to_kdev_t you search for "scd" but
> set tp to "sr".
> That should also be "scd" I'd guess.
No, it's intended. Internally, I use the name 'sr' for a SCSI CDrom as
that's the name the driver advertises. Some strange distributions out there
seem to prefer the name 'scd' for unknown reasons[*], that's why I map scd to
sr in order not to confuse users.
[*] The file name of the driver is sr.c, the module is name sr_mod, it fills
in the tag 'sr' as driver name (which is reported in /proc/devices).
But for some reason somebody thinks that 'scd' would be more user friendly.
It may seem more intuitive at first sight, but it makes things completely
inconsistent. Unless, of course, we rename everything to 'scd' to make it
consistent again.
It nowadays is even reported as 'scd' (and 'sr' deprecated) in devices.txt,
sigh!
Somebody should take an authorative decision and do the renames if necessary!
Or make sure devices.txt is fixed. Jens?
Regards,
--
Kurt Garloff <[email protected]> [Eindhoven, NL]
Physics: Plasma simulations <[email protected]> [TU Eindhoven, NL]
Linux: SCSI, Security <[email protected]> [SuSE Nuernberg, DE]
(See mail header or public key servers for PGP2 and GPG public keys.)