[openib-general] [PATCH v2 1/2] ofed_1_2 Changes to kernel_patches/ forChelsioT3 Support.

[Michael S. Tsirkin]

> > > Quoting Michael S. Tsirkin <mst at mellanox.co.il>:
> > > Subject: Re: [PATCH v2 1/2] ofed_1_2 Changes to kernel_patches/ for ChelsioT3 Support.
> > > 
> > > 
> > > > What if its already built in and export in the kernel we're trying to
> > > > load into?  Will this cause a load problem?  I was assuming it
> > > > would...that's why I changed the names.  Am I wrong?
> > > 
> > > BTW, if you want to change a definition of an existing symbol,
> > > you can use macro trick like the folowing (this is from
> > > ./2.6.9_U2/include/net/sock.h):
> > > 
> > > static inline
> > > void sock_init_data_new(struct socket *sock, struct sock *sk)
> > > {
> > > 	        sock_init_data(sock, sk);
> > > 		        sk->sk_owner = THIS_MODULE;
> > > }
> > > 
> > > #define sock_init_data sock_init_data_new
> > 
> > Another final note: I am not sure it makes sense to try supporting
> > 2.6.20 with CONFIG_GENERIC_ALLOCATOR turned off.
> > Distributions typically just enable everything so I think this won't
> > be a problem in practice.
> > 
> > What do you think?
> 
> There is no way to enable this option via make menuconfig.  It is only
> enabled if some other subsystem requires it by adding this to their
> Kconfig:
> 
> select GENERIC_ALLOCATOR

I know, but what I'm saying is that distros tend to enable all drivers
so in practice it will be enabled.

> I think the best solution is to treat it as a backport, change the names
> (either explicitly or with a #define trick) and back-port it to every
> kernel version we're going to support.

I'm not yet convinced the problem exists. I would suggest look at RHEL5.
If that has genalloc enabled its a good indication that you don't
need to put a copy of it in OFED.


-- 
MST