Re: [PATCH 0/2] kbuild updates

[Sam Ravnborg]

On Tue, Jun 22, 2004 at 08:29:55AM +0300, Jari Ruusu wrote:
> Sam Ravnborg wrote:
> > On Mon, Jun 21, 2004 at 12:03:19AM +0200, Sam Ravnborg wrote:
> > > If I get just one good example I will go for the object directory, but
> > > what I have seen so far is whining - no examples.
> > 
> > Now I recall why I did not like the object directory.
> > I will break all modules using the kbuild infrastructure!
> 
> No it does not. If 'export KBUILD_OUTPUT=/foo' command is used used before
> kernel is built, it is not any more difficult to compile external modules
> with that same env variable defined.
> 
> > Why, because there is no way the to find the output directory except
> > specifying both directories.
> > One could do:
> > make -C /lib/modules/`uname -r`/source O=/lib/modules/`uname -r`/build M=`pwd`
> > 
> > So the currect choice is:
> > 1) Break modules that actually dive into the src, grepping, including or whatever
> > 2) Break all modules using kbuild infrastructure, including the above ones
> 
> or 3) Add the missing object symlink. It does not break anything.

This is unfortunately not the case.
First a few facts.
The documented way to build external modules has for a while now been
to use the following command:

	make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` modules

Recently this was simplifed to

	make -C /lib/modules/`uname -r`/build M=`pwd`

As you pointed out in a previous post letting build point to the
output directory would break all existing drivers using the documented
approach, iff the kernel were compiled using a separate output directory.
So the breakage that was of a concern was how to build external
modules using the above command - but having the kernel build
using a separate output directory.
The was solved by adding a small makefile in the output directory.

So the situation with the patch posted is that all ordinary modules
compile independent of the kernel is compiled with separate output
directories or not.

The problem you point out is modules that to be backward compatible
needs access to the kernel source. This is solved in different ways:
a) Grepping the source direct
b) Compiling a small code fragment, and test if the .o file exists

Knowing your background you are most familiar with the a) approach.
Therefore I understand why you prefer to set an environment variable
and otherwise use your current makefile.
But doing so will break all 'ordinary' external modules.
The ordinary modules are adapted to use the above commands
to compile the module.
But if the build symlinks points to the source of the
kernel and the kernel uses separate directory for output files then
it is missing the possibility to:
- access .config
- use kbuild infrastructure
- include headers under asm symlink

All the abvoe are fatal.
The porposal to require the user to set KBUILD_OUTPUT before
compiling the module would fix this. But this is then a change
in the required command used to compile an 'ordinary' external module.
It would then look like:

	KBUILD_OUTPUT=/lib/modules/`uname -r`/object; make -C /lib/modules/`uname -r`/build M=`pwd`

This change is not acceptable.
The tradeoff is that external modules that needs access to the source
needs to be tweaked to support kernels build using separate output and
source directories.

So the final result is that external modules that needs access to
the source is broken iff the kernel uses separate output directories.


> > I go for 1), introducing minimal breakage.
> 
> You seem to be in some strange "I must destroy... I must destroy... I must
> destroy..." mental state. There is a no-breakage alternative and you just
> will not consider that at all.

Requiring user to set an environment variable in many common cases
are breakage.

	Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/