[ewg] Re: [ofa-general] ofed autoconf.h

[Brian J. Murrell]

Hi Steve,

Thanx for looking into these two items for us.

On Tue, 2009-04-07 at 16:24 -0500, Steve Wise wrote:
> I've been charged to resolve OFED bugs 1538 and 1578 dealing with 
> autoconf.h.  I seek input from the OFA lists.

For the record of discussion, I opened these two bugs.

> It was suggested that we could add a "#include_next 
> <linux/autoconf.h>" to the ofed file and thus include both, but that 
> doesn't work because we need the backing kernel autoconf.h included 
> first, and then the ofed one.

Isn't that just a function of where you put the #include_next in the
ofed autoconf.h?  If you put it at the top, the ofed autoconf.h will
override anything in the backing kernel autoconf.h but if you put it at
the bottom, the backing kernel's autoconf.h overrides values set in the
ofed autoconf.h, no?

> I think the idea originally was 
> that the backing kernel didn't have any of these ofed modules.

That was my suspicion as well -- that this grew out of something that
was acceptable to do before the OFED stack started providing more of
what the backing kernel could be providing.

> 1) do we think these should be resolved in ofed-1.4.1?

I would really like to see them resolved in the 1.4.1 release as we have
already missed the 1.4.0 release due to other external-module build
problems.

> Here are my proposed solutions (dunno if they break anything)
> 
> 1538:  change the ofed configure script to create a fully-populated 
> autoconf.h that basically is a cat of the back kernel tree autoconf.h 
> and the current ofed autoconf.h.  That way, modules will get everything 
> when they include the ofed autoconf.h.

What happens then if the user changes something in their kernel
configuration (i.e. after having built kernel-ib{,-devel} and installing
kernel-ib-devel) which is completely independent of OFED, like, say
enabling the serial module?

I'm definitely no module versioning expert, but I think such a change
would be allowable and not invalidate the modules in kernel-ib,  If
anyone knows better than I, please do correct me here.

But in such a case, "#include <linux/autoconf.h>" will not reflect that
kernel configuration change.  This is not to say that such an operation
will be common, but I'm just trying to find the solution that covers the
most use-cases and still achieves our goal.

Is this solution to merge the backing kernel's autoconf.h into the ofed
one because of the perceived inability to use #include_next to
effectively concat the files at (external module) compile time?  Does my
suggestion as to positioning of the #include_next <linux/autoconf.h> in
the ofed autoconf.h change your thoughts on the best solution to this
problem?

> 1578: I propose we don't #undef any modules that are not configured into 
> the ofed build.

Yes.  This was my proposal as well.

> Thus if you don't build in NFSRDMA for ofed, the status 
> of the NFS CONFIG* defines will be based on the backing kernel tree 
> autoconf.h instead of always being turned off.

This is the solution I like.  The use-case this covers is that I want to
use infiniband in my network (for something other than NFS) and don't
want to use the NFSRDMA supplied by the OFED stack and instead want to
use the kernel's own provided NFS stack.  Not replacing the vendor
kernel supplied NFS stack reduces our risk and maintenance efforts.

b.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20090408/801d6f22/attachment.sig>