Hi,
We (LSI MegaRAID team) are working on enhancing the functionality of the MegaRAID driver. These enhancements include support for next generation HBAs.
The new generation HBA interface would be significant different than the current interface. There would not be any changes for raid management application driver interfaces though.
We are anticipating about 70-80% of the current driver code to be changed. These changes would not be functional in nature though. The current functionality would be re-aligned in supporting functions. A parallel stream of functions would be created to support new HBAs.
We are not anticipating changes in ways the new driver would work with the current generation of the HBAs and therefore we do not foresee any impact on the current functionality for these HBAs.
We would like to solicit community feedback if this approach is acceptable. Alternative would be to leave the current driver untouched and submit a new driver for next generation of HBAs.
Your inputs would be highly appreciated.
Regards,
Atul Mukker
LSI Corp.-
On Mon, Feb 15, 2010 at 10:09:23AM -0700, Mukker, Atul wrote:
> We are anticipating about 70-80% of the current driver code to be changed. These changes would not be functional in nature though. The current functionality would be re-aligned in supporting functions. A parallel stream of functions would be created to support new HBAs.
>
> We are not anticipating changes in ways the new driver would work with the current generation of the HBAs and therefore we do not foresee any impact on the current functionality for these HBAs.
>
> We would like to solicit community feedback if this approach is acceptable. Alternative would be to leave the current driver untouched and submit a new driver for next generation of HBAs.
>
> Your inputs would be highly appreciated.
Please just add a new megaraid_<foo> driver, similar to how megaraid_sas
is split from the legacy megaraid driver. If the shared code is easy
enough to factor it could be moved into a megaraid_common module, but
in doubt I would not even bother with that.
Thanks for the inputs Christoph.
We sort of had an idea for this possible route. What are your biggest concerns for a single driver model?
The split model has implications for LSI RAID management applications and we want to make sure that decision is made with a thorough analysis.
Regards,
Atul
> -----Original Message-----
> From: Christoph Hellwig [mailto:[email protected]]
> Sent: Monday, February 15, 2010 1:18 PM
> To: Mukker, Atul
> Cc: [email protected]; [email protected]
> Subject: Re: [RFC]: new LSI MegaRAID driver implementation
>
> On Mon, Feb 15, 2010 at 10:09:23AM -0700, Mukker, Atul wrote:
> > We are anticipating about 70-80% of the current driver code to be
> changed. These changes would not be functional in nature though. The
> current functionality would be re-aligned in supporting functions. A
> parallel stream of functions would be created to support new HBAs.
> >
> > We are not anticipating changes in ways the new driver would work
> with the current generation of the HBAs and therefore we do not foresee
> any impact on the current functionality for these HBAs.
> >
> > We would like to solicit community feedback if this approach is
> acceptable. Alternative would be to leave the current driver untouched
> and submit a new driver for next generation of HBAs.
> >
> > Your inputs would be highly appreciated.
>
> Please just add a new megaraid_<foo> driver, similar to how
> megaraid_sas
> is split from the legacy megaraid driver. If the shared code is easy
> enough to factor it could be moved into a megaraid_common module, but
> in doubt I would not even bother with that.
On Tue, Feb 16, 2010 at 09:37:14AM -0700, Mukker, Atul wrote:
> Thanks for the inputs Christoph.
>
> We sort of had an idea for this possible route. What are your biggest concerns for a single driver model?
My biggest concern is that you'll do something to fix a bug in the new
hardware and inadvertently create a bug for some old piece of hardware.
> The split model has implications for LSI RAID management applications and we want to make sure that decision is made with a thorough analysis.
I'm not sure I see the downside to having a second driver.
One interesting possibility, if you feel you really must have a single driver that handles both sets of hardware is to do this:
------
a.c:
struct pci_driver a_pci_driver { ... };
b.c:
struct pci_driver b_pci_driver { ... };
common.c:
static int __init my_init(void)
{
error = pci_register_driver(&a_pci_driver);
if (error)
return error;
error = pci_register_driver(&b_pci_driver);
if (error)
pci_unregister_driver(&a_pci_driver);
return error;
}
module_init(my_init);
------
Now you have two completely separated drivers which are bound together
into a single object file. Bit wasteful, but might make your management
happier.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."