megaraid driver (proposed patch)

megaraid driver (proposed patch)

[Bruno Cornec]

Hello,

I've noticed that since recent kernel versions, it's not possible
anymore to use simultaneously new and old megaraid driver. 

It seems to have been introduced by that changeset:
http://linux.bkbits.net:8080/linux-2.5/diffs/drivers/scsi/megaraid/Kconfig.megaraid@1.1??nav=index.html|src/.|src/drivers|src/drivers/scsi|src/drivers/scsi/megaraid|hist/drivers/scsi/megaraid/Kconfig.megaraid

It particularly makes life of people developing kernel for distro
difficult as it forces them to drop support for legacy hardware which is
working just fine with 2.6, or to patch their own kernel build.
As well it prevents simultaneous usage of new and old cards in the same
system.

Would you consider to apply the following patch proposed by Thierry
Vignaud as a solution for the MandrakeSoft kernel in the mainstream 2.6 
kernel ?

Thanks in advance,
Bruno.

--- ./drivers/scsi/megaraid/Kconfig.megaraid	2005-03-02
08:37:49.000000000 +0100
+++ ./drivers/scsi/megaraid/Kconfig.megaraid	2005-03-25
18:36:37.809994244 +0100
@@ -64,7 +64,6 @@
 	To compile this driver as a module, choose M here: the
 	module will be called megaraid_mbox
 
-if MEGARAID_NEWGEN=n
 config MEGARAID_LEGACY
 	tristate "LSI Logic Legacy MegaRAID Driver"
 	depends on PCI && SCSI
@@ -75,4 +74,3 @@
 
 	To compile this driver as a module, choose M here: the
 	module will be called megaraid
-endif
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: megaraid driver (proposed patch)

[James Bottomley]

On Fri, 2005-03-25 at 19:22 +0100, Bruno Cornec wrote:
> Would you consider to apply the following patch proposed by Thierry
> Vignaud as a solution for the MandrakeSoft kernel in the mainstream 2.6 
> kernel ?

Well, to be considered you'd need to cc the megaraid maintainers and the
linux-scsi mailing list.

> -if MEGARAID_NEWGEN=n

No, this is wrong it would break allyes configs and I'd get shot.

James

Re: megaraid driver (proposed patch)

[Christoph Hellwig]

On Fri, Mar 25, 2005 at 12:39:52PM -0600, James Bottomley wrote:
> On Fri, 2005-03-25 at 19:22 +0100, Bruno Cornec wrote:
> > Would you consider to apply the following patch proposed by Thierry
> > Vignaud as a solution for the MandrakeSoft kernel in the mainstream 2.6 
> > kernel ?
> 
> Well, to be considered you'd need to cc the megaraid maintainers and the
> linux-scsi mailing list.
> 
> > -if MEGARAID_NEWGEN=n
> 
> No, this is wrong it would break allyes configs and I'd get shot.

Why?  The megaraid drivers shouldn't have any conflicting non-static
symbols

Re: megaraid driver (proposed patch)

[James Bottomley]

On Fri, 2005-03-25 at 18:47 +0000, Christoph Hellwig wrote:
> On Fri, Mar 25, 2005 at 12:39:52PM -0600, James Bottomley wrote:
> > On Fri, 2005-03-25 at 19:22 +0100, Bruno Cornec wrote:
> > > Would you consider to apply the following patch proposed by Thierry
> > > Vignaud as a solution for the MandrakeSoft kernel in the mainstream 2.6 
> > > kernel ?
> > 
> > Well, to be considered you'd need to cc the megaraid maintainers and the
> > linux-scsi mailing list.
> > 
> > > -if MEGARAID_NEWGEN=n
> > 
> > No, this is wrong it would break allyes configs and I'd get shot.
> 
> Why?  The megaraid drivers shouldn't have any conflicting non-static
> symbols

You get a kernel with two drivers trying to claim some of the same set
of cards.  The winner will be the driver that gets its init routines
called first, but this isn't a desirable outcome.

I wouldn't object to a patch that allows both *modules* to be built,
which is all I think the distros are after.

James

Re: megaraid driver (proposed patch)

[Christoph Hellwig]

On Fri, Mar 25, 2005 at 01:04:37PM -0600, James Bottomley wrote:
> You get a kernel with two drivers trying to claim some of the same set
> of cards.  The winner will be the driver that gets its init routines
> called first, but this isn't a desirable outcome.
> 
> I wouldn't object to a patch that allows both *modules* to be built,
> which is all I think the distros are after.

The new megaraid driver doesn't support old hardware.  Maybe we should
drop the overlapping pci ids from the old driver?

Re: megaraid driver (proposed patch)

[Ricardo Colon]

Can someone please remove me from these mailing lists?

I don't remember signing up ffor them and it's filling
my inbox too quickly.

On Fri, 25 Mar 2005, Christoph Hellwig wrote:

> On Fri, Mar 25, 2005 at 01:04:37PM -0600, James Bottomley wrote:
>> You get a kernel with two drivers trying to claim some of the same set
>> of cards.  The winner will be the driver that gets its init routines
>> called first, but this isn't a desirable outcome.
>>
>> I wouldn't object to a patch that allows both *modules* to be built,
>> which is all I think the distros are after.
>
> The new megaraid driver doesn't support old hardware.  Maybe we should
> drop the overlapping pci ids from the old driver?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: megaraid driver (proposed patch)

[James Bottomley]

On Fri, 2005-03-25 at 19:07 +0000, Christoph Hellwig wrote:
> The new megaraid driver doesn't support old hardware.  Maybe we should
> drop the overlapping pci ids from the old driver?

That works for me too ... but the people who get to decide what to do
should be the driver maintainers.

James

Re: megaraid driver (proposed patch)

[Bruno Cornec]

Hello,

After a first attempt of discussion on lkml, I'd like to get your
feedback on the following points.

I've noticed that since recent kernel versions, it's not possible
anymore to use simultaneously new and old megaraid driver.

It seems to have been introduced by that changeset:
http://linux.bkbits.net:8080/linux-2.5/diffs/drivers/scsi/megaraid/Kconfig.megar
aid@1.1??nav=index.html|src/.|src/drivers|src/drivers/scsi|src/drivers/scsi/mega
raid|hist/drivers/scsi/megaraid/Kconfig.megaraid

It particularly makes life of people developing kernel for distro
difficult as it forces them to drop support for legacy hardware which is
working just fine with 2.6, or to patch their own kernel build.
As well it prevents simultaneous usage of new and old cards in the same
system.

As notes by James Bottomley and Christoph Hellwig the best thing to do
is probably to remove support for cards in the old driver that are still
supported by the new driver.

I'd like to propose a patch but looking at the code I have the following
question: the card id 101E:1960 seems to be supported by the new driver
as per the header of megaraid_mbox.c but in reality I was unable to boot
my system which uses that precise card with the new driver.

Are they mistakes in the header file ? Should they be removed from the
new driver (if they don't work) or from the old if they work ?

My current status is the following (just for discussion)

diff -Nru drivers/scsi/megaraid/Kconfig.megaraid
drivers.new/scsi/megaraid/Kconfig.megaraid
--- drivers/scsi/megaraid/Kconfig.megaraid      Fri Mar 25 20:34:06 2005
+++ drivers.new/scsi/megaraid/Kconfig.megaraid  Fri Mar 25 20:53:37 2005
@@ -64,15 +64,12 @@
        To compile this driver as a module, choose M here: the
        module will be called megaraid_mbox
 
-if MEGARAID_NEWGEN=n
 config MEGARAID_LEGACY
        tristate "LSI Logic Legacy MegaRAID Driver"
        depends on PCI && SCSI
        help
        This driver supports the LSI MegaRAID 418, 428, 438, 466, 762,
490
-       and 467 SCSI host adapters. This driver also support the all
        U320
-       RAID controllers
+       and 467 SCSI host adapters.
 
        To compile this driver as a module, choose M here: the
        module will be called megaraid
-endif
diff -Nru drivers/scsi/megaraid.c drivers.new/scsi/megaraid.c
--- drivers/scsi/megaraid.c     Fri Mar 25 20:28:29 2005
+++ drivers.new/scsi/megaraid.c Fri Mar 25 20:57:25 2005
@@ -5033,12 +5033,6 @@
 }
 
 static struct pci_device_id megaraid_pci_tbl[] = {
-       {PCI_VENDOR_ID_DELL, PCI_DEVICE_ID_DISCOVERY,
-               PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
-       {PCI_VENDOR_ID_DELL, PCI_DEVICE_ID_PERC4_DI,
-               PCI_ANY_ID, PCI_ANY_ID, 0, 0, BOARD_64BIT},
-       {PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_PERC4_QC_VERDE,
-               PCI_ANY_ID, PCI_ANY_ID, 0, 0, BOARD_64BIT},
        {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID,
                PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
        {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID2,
diff -Nru drivers/scsi/megaraid.h drivers.new/scsi/megaraid.h
--- drivers/scsi/megaraid.h     Fri Mar 25 20:28:25 2005
+++ drivers.new/scsi/megaraid.h Fri Mar 25 20:57:03 2005
@@ -73,10 +73,6 @@
 #define PCI_DEVICE_ID_AMI_MEGARAID3    0x1960
 #endif
 
-#define PCI_DEVICE_ID_DISCOVERY                0x000E
-#define PCI_DEVICE_ID_PERC4_DI         0x000F
-#define PCI_DEVICE_ID_PERC4_QC_VERDE   0x0407
-
 /* Sub-System Vendor IDs */
 #define        AMI_SUBSYS_VID                  0x101E
 #define DELL_SUBSYS_VID                        0x1028

-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: megaraid driver (proposed patch)

[Thierry Vignaud]

James Bottomley <jejb@steeleye.com> writes:

> > > > Would you consider to apply the following patch proposed by
> > > > Thierry Vignaud as a solution for the MandrakeSoft kernel in
> > > > the mainstream 2.6 kernel ?
> > > 
> > > Well, to be considered you'd need to cc the megaraid maintainers
> > > and the linux-scsi mailing list.
> > > 
> > > > -if MEGARAID_NEWGEN=n
> > > 
> > > No, this is wrong it would break allyes configs and I'd get shot.
> > 
> > Why?  The megaraid drivers shouldn't have any conflicting
> > non-static symbols
> 
> You get a kernel with two drivers trying to claim some of the same
> set of cards.  The winner will be the driver that gets its init
> routines called first, but this isn't a desirable outcome.

well, this is not the first occurence:

- one can build both oss and alsa drivers which claimed quite the same
  ids set.
eg, one example from modules.pcimap:
snd-intel8x0         0x00001039 0x00007012 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
i810_audio           0x00001039 0x00007012 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0

- at one point, atiixp and sata_sil used to overlap on one sata
  controller
- tg3 and bcm5700 totally overlap
- the same for e100 and eepro100, e1000 and eepro1000
- sata drivers ahci and ata_piix used to overlap too on a cople of
  devices
- b44 and bcm4400 totally overlap
- 8139too and 8139cp overlap
- i2c-ali15x3 and i2c-ali1535 overlap too
- qla6322 and qla6312 used to overlap in the past
- via-ircc and i2c-viapro overlaps
- dvb
- saa7134 and saa7134-dvb overlap
- sonypi and i2c-piix4 overlap
- cx88 and cx88-dvb overlap
- radio-gemtek-pci and radio-maxiradio overlap too
- ...

so this argument looks totally bogus for me since few of these drivers
prevent them being build in-core at both time b/c there're quite a lot
of other driver that will "break"  allyes configs

> I wouldn't object to a patch that allows both *modules* to be built,
> which is all I think the distros are after.

indeed. but the first patch should have been accpeted as this.

the in fact policy isn't currently to prevent overlapping drivers to
being compiled in-core at the same time, so i think we shouldn't
prevent it but convert all these drivers' build rules so that they
allow to be built as modules at the same time, but not in core at the
same time

Re: megaraid driver (proposed patch)

[Christoph Hellwig]

> - tg3 and bcm5700 totally overlap

bcm5700 isn't in the tree.

> - the same for e100 and eepro100, e1000 and eepro1000

there's no eepro1000

> - sata drivers ahci and ata_piix used to overlap too on a cople of
>   devices
> - b44 and bcm4400 totally overlap

bcm4000 isn't in the tree