[openib-general] Re: [RFC] Move InfiniBand .h files

Sam Ravnborg sam at ravnborg.org
Thu Aug 4 13:02:45 PDT 2005


On Thu, Aug 04, 2005 at 01:54:56PM -0600, Christopher Friesen wrote:
> Sam Ravnborg wrote:
> >On Thu, Aug 04, 2005 at 11:57:55AM -0700, Roland Dreier wrote:
> 
> >>Sorry, I was too terse about the problem.  You're right, but typical
> >>distros don't ship full kernel source in their "support kernel builds"
> >>package.  And if I use an external build directory (ie "O=") then
> >>the symlink just points to my external build directory, which doesn't
> >>include the source to drivers/, just links to include/
> >
> >
> >If the external module uses a Kbuild file as explained in
> >Documentation/kbuild/makefiles.txt and then uses both O= and M=
> >when compiling the module there is no issue.
> >
> >With respect to moving the .h files - please do so.
> >drivers/infiniband should only include header used in that same
> >directory. Not header files potentially uased by fs/.
> 
> I think Roland was talking about the case where the running kernel was 
> built with "O=", in which case the /lib/modules.../build symlink points 
> to the build directory rather than the original source tree.
> 
> Does Kbuild handle this case properly?

Yes it does.
/lib/modules/.../ contains two symlinks these days:

build -> always point to the directory containing the output of the build
source -> always point to the kernel source

In the 'make' case where the kernel is built without using O= they point
to the same directory.
In the 'make O=' case they point to different directories.

SUSE does ship with a make O= build kernel these days.
Fedora IIRC has done an ugly hack and just copied over a number of files
so a compile works in most cases - but then also use both symlink.

It has never been easier to build a module if the target is only the
running kernel. Only when you adds backwards compatibility it gets messy :-(

	Sam



More information about the general mailing list