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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
