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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ewg mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
