Re: [PATCH 0/2] kbuild updates

[Sam Ravnborg <sam@ravnborg.org>]

On Mon, Jun 21, 2004 at 01:51:43AM +0200, Andreas Gruenbacher wrote:
> > But my original concern (that the only way to figure where the source
> > are for the running kernel will be broken) is still valid.
> 
> User-space stuff that needs access to kernel headers at build time is a 
> problem. But for those programs, depending on the running kernel instead of 
> simply looking in /usr/src/linux is an even bigger problem: What guarantees 
> that the first time the program is run, the kernel will still be the same? So 
> depending on the running kernel is definitely wrong. Depending 
> on /usr/src/linux is also wrong; ideally those programs should look 
> in /usr/include/{linux,asm}. Unfortunately these headers are not always 
> recent enough, and so recently added definitions may be missing.

But Martin has a point here.
How to figure out for example the number of arguments to remap_page_range.
One could do some grepping in the mm.h file, or one could try to compile
a minimal module calling this function.
If we go for the simple version by grepping we need to figure out where
to find the source. In the past this was simple - just follow the
build symlink. But now kernels may be shipped with separate source
and output directory exposing the weakness of this method.
A much more reliable way is to build a simple module.
If the module build succeeds that specific version
of remap_page_range is OK.

nvidia does something similar, but they take the false assumption
that the running kernel is always the one being build for.
So they call gcc direct.

Other modules uses the grep method - which will fail when the kernel
is build with separate output and source directories.

> 
> > Makefile-pre_M_flag - 100% valid kbuild Makefile for kernels that
> >                       do not support M=
> >
> > Makefile-post_M_flag - 100% valid kbuild Makefile for kernels
> >                        supporting M=
> 
> Right now I would collapse the pre/post Makefiles and use SUBDIRS instead. 
> There is no easy and reliable test for M= support, and it's only cosmetic. 
> Sam will probably disagree.

SUBDIRS were kept for backward compatibility - and I realise it will stay
for a long time. The implementation were kept straightforward so no problem.

	Sam