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

[Steve Wise]

Brian J. Murrell wrote:
> 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?
>
>   


Maybe.  I thought include_next included it after the existing file was 
processed.  Maybe I'm all wet though.  I'll run experiments.  If you're 
right, then my original patch to the configure script will handle 1538.



>> 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.
>
>   


You can always work around these issues, yes?


>> 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?
>   


You have to rebuild/reinstall ofed if you change the backing kernel.


> 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.
>
>   


If the include_next solution works, then we're all set...


> 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?
>   

I'll let you know.


>   
>> 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.
>
>   

This does expose an issue, however.  If an ofed release changes the 
kernel verbs or cm APIs, then it can break  any rdma kernel modules that 
do not get rebuilt against the ofed headers.  But this issue has always 
been there I guess. 


Steve.