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

Steve Wise swise at opengridcomputing.com
Thu Jan 11 15:28:42 PST 2007


On Fri, 2007-01-12 at 01:25 +0200, Michael S. Tsirkin wrote:
> > 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 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.









More information about the general mailing list