RE: [RFC]: new LSI MegaRAID driver implementation

[Mukker, Atul]

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:hch@xxxxxxxxxxxxx]
> Sent: Monday, February 15, 2010 1:18 PM
> To: Mukker, Atul
> Cc: linux-scsi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/