Some help about backporting a nic module to 2.6.32 longterm

[deferraz@terra.com.br (André Ferraz)]

Hi Greg,
	the problem is that i need to stay with the 2.6.32 grsec
	patchset for my servers, if i didn't have any dependencies like
	that sure i'll be using the 3.2 kernel.

	The idea is to just backport this device driver, the rest of
	the drivers works pretty well, but i didnt find any HowTo or
	some documentation specific to the process of update a driver
	on your kernel source.


[]s

On Mon, 9 Jan 2012 14:49:51 -0800
Greg KH <greg@kroah.com> wrote:

> On Mon, Jan 09, 2012 at 07:19:18PM -0200, Andr? Ferraz wrote:
> > Hi,
> > 
> > 	I'm using the 2.6.32.x longterm series for our servers but
> > we are facing a problem with the bnx2x driver module in our latest
> > 	G7 HP blade servers, the module exists but it doenst ping
> > and cant access any node in the network, i saw too that the
> > 	broadcom and hp driver specs can't build on 2.6.32 kernel
> > 	because they only support the 2.6.18 redhat series. The
> > version maintained by CentOS/Redhat om 5.x release works but it is
> > 	based on 2.6.18 kernel.
> > 
> > 	My initial idea was pull the CentOS 6 kernel source (based
> > on 2.6.32) and make a patch of the bnx2x driver for my kernel
> > 	source, the patch applies but when i boot the kernel the
> > 	version it remains the same, i saw that the /firmware
> > directory has some bnx2x files on it, my question to you is that i
> > 	couldnt find anywhere is how the .c file and the .fw
> > 	correlates , or , how can i create a real backport of this
> > 	driver so i can use an usable version of the driver for the
> > 	longterm release?
> 
> Why not just use the 3.2 kernel release, where this should be fixed
> already, right?
> 
> Once you start backporting "bits and pieces", you can quickly end up
> with an unmaintainable mess, not to mention something that no one,
> including the community, or any company, will ever support.
> 
> greg k-h
>