linux-kernel - RE: [RFC]: new LSI MegaRAID driver implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Feb 2010 09:37:14 -0700
From:	"Mukker, Atul" <Atul.Mukker@....com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC]: new LSI MegaRAID driver implementation

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@...radead.org]
> Sent: Monday, February 15, 2010 1:18 PM
> To: Mukker, Atul
> Cc: linux-scsi@...r.kernel.org; linux-kernel@...r.kernel.org
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/