Re: [PATCH 0/2] kbuild updates

[Martin Schlemmer]

On Tue, 2004-06-22 at 00:31, Sam Ravnborg wrote:
> 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.
> 

Might it help if there was some silly 'external module example toolkit'
or whatever, that shows how to figure out with kbuild how to determine
srcdir, figure out how many args remap_page_range takes, etc?

I will admit that most fixes I do to external modules is maybe not
really because their build systems is 'buggy' as such, but more because
of short-sightedness and lack of understanding kbuild.  So above should
help.

Yeah, another project to maintain (in kernel if possible?).  I am
willing to try at some of the tests, but my docs skills is no where
good ... :/


Thanks,

-- 
Martin Schlemmer

Attachment: signature.asc
Description: This is a digitally signed message part