[ofa-general] IB function calls in kernel module fail

[Brian J. Murrell]

On Wed, 2009-02-18 at 16:40 +0200, Tziporet Koren wrote:
> Brian J. Murrell wrote:
> > Ahhh.  But should he just include <ofed-prefix>/src/openib/include/ or
> > also
> > <ofed-prefix>/src/openib/kernel_addons/backport/<kernel_ver>/include/
> > (as described in <ofed-prefix>/src/openib/ofed_patch.mk as well?
> >
> > And in what order should these be specified in?
> >
> >   
> You need both
> Order not important

Are you sure about this?  I have been, in the past, unsure about this
ordering too, but have been seeing evidence that order is important.

Take for example in the current ~vlad/ofed_kernel-1.4 tree, there is an
exportfs.h in both <ofed-prefix>/src/openib/include/linux and
<ofed-prefix>/src/openib/kernel_addons/backport/2.6.16_sles10_sp2/include/linux.

Having discussed the presence of this (newish) header in the SLES10 SP2
backports tree with Jeff it's clear that it should be used in preference
to the one in the general include tree.

Therefore, if one is not careful about ordering (so that backport
headers take precedence) over the general ones, one would get the wrong
exportfs.h header for SLES10 SP2 builds.

But then there is the question of the kernel headers and ordering.  Many
of backport headers use #include_next to get the next found instance of
a header.  I have always assumed that was to get the kernel's version of
a header included in the backport header.  But if the order is:

     1. backports headers
     2. ofa general headers
     3. kernel headers

then an "#include_next <foo.h>" in
<ofed-prefix>/src/openib/kernel_addons/backport/<kernel_ver>/include/linux/foo.h could potentially pick up <ofed-prefix>/src/openib/include/linux/foo.h rather than <kernel_source>/include/linux/foo.h which I think is what is intended/desired in most cases.

But if the ordering is changed to:

     1. backports headers
     2. kernel headers
     3. ofa general headers

Then the desired preference of
<ofed-prefix>/src/openib/include/{rdma,scsi}/* headers vs. the ones
included in the kernel will be lost.

How can we reconcile this?

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/20090219/2366a698/attachment.sig>