[ofa-general] ofed autoconf.h

[Brian J. Murrell]

On Wed, 2009-04-08 at 09:27 -0500, Steve Wise wrote:
> 
> Maybe.  I thought include_next included it after the existing file was 
> processed.

Hrm.  You could be right about that.  My interpretation was always that
it included it immediately, as if the contents of the #include_next
files were actually in the caller's file right where the #include_next
is.

> Maybe I'm all wet though.

Or maybe it's me who is all wet.  :-)

> I'll run experiments.

I just did.  It seems to work as I thought.  You do get macro
redefinition warnings though for something defined in both files:

bar/a.h:1:1: warning: "FOO" redefined

which will be an error if you build with -Werror.  :-(

If including the kernel's autoconf.h *before* doing all of the OFED
macros is the right solution (which I think it is) the warnings can be
fixed by doing:

#include_next <autoconf.h>

#undef FOO
#define FOO 1

But relative to bug 1578, I'd only want to see macros which are to be
set to something "#undef"ed first and not have every macro "#undef"ed
wholesale.

> If you're 
> right, then my original patch to the configure script will handle 1538.

Yes, indeed.

> You can always work around these issues, yes?

Yeah.  It's ugly though.  It essentially winds up being your "cat"
solution (with some "#undef" removals to address bug 1578), to create a
third autoconf.h in a temporary directory (which is basically a union of
the two files) and put that temporary directory in the include path
before the OFED include and backing kernel include paths.

This is a hack that will need to be undone in a future Lustre release
when this issue is resolved.

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

Hrm.  Even if I change something completely unrelated to OFED or
networking at all, like say just changing CONFIG_SERIAL_8250 from m to
y?

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

Indeed.  I think so too.

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

Yeah.  I was considering that as well WRT to bug 1578 and not wholesale
"#undef"ing all macros leading to a mixture of kernel provided and OFED
provided RDMA options.

I wonder if this is something that is appropriate to do at (OFED0
configure time, and simply bail if a mismatch is found with a "you can't
do that.  either change your ofed selections or disable FOO in your
kernel configuration" type error message.

I don't think this particular problem is something we need to address
for 1.4.1 though.

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/general/attachments/20090408/e832b7d4/attachment.sig>