Re: [PATCH 0/2] kbuild updates

[Martin Schlemmer <azarah@nosferatu.za.org>]

[-- Attachment #1: Type: text/plain, Size: 3828 bytes --]

On Mon, 2004-06-21 at 00:26, Andreas Gruenbacher wrote:
> On Sunday 20 June 2004 23:52, Martin Schlemmer wrote:
> > On Sun, 2004-06-20 at 23:42, Arjan van de Ven wrote:
> > > > Given, but to 'use' the kbuild infrastructure, you must still call it
> > > > via:
> > > >
> > > >   make -C _path_to_sources M=`pwd`
> > >
> > > I see no problem with requiring this though; requiring a correct
> > > makefile is perfectly fine with me, and this is the only and documented
> > > way for 2.6 already.
> > > (And it's also the only way to build modules against Fedora Core 2
> > > kernels by the way)
> >
> > I did not mean I have a problem with that.  Say you take svgalib, and
> > you want the build system to automatically compile the kernel module,
> > you might do something like:
> >
> > ---
> > build_2_6_module:
> > 	@make -C /lib/modules/`uname -r`/build M=`PWD`
> > ---
> >
> > will break with proposed patch ...
> 
> No it won't.
> 
> You always need to figure out $(objtree) to build external modules, with or 
> without a separate output directory. Many modules don't need to know 
> $(srctree) explicitly at all.
> 
> In case you want to do something depending on the sources/confguration, there 
> are two ways:
>   - follow the new source symlink,
>   - let kbuild take you to $(srctree): When the makefile in the M directory
>     is included, the current working directory is $(srctree). besides, all the
>     usual variables like $(srctree), $(objtree), CONFIG_* variables, etc. are
>     all available. That's a good time to check for features, etc.
> 

But my original concern (that the only way to figure where the source
are for the running kernel will be broken) is still valid.  And to do
all that you mentioned above, you still need to figure out _where_ the
kernel source are ...

> > And the point I wanted to make was that AFIAK
> > '/lib/modules/`uname -r`/build' is an interface to figure
> > out where the _sources_ for the current running kernel are
> > located.
> 
> That's a misconception. At the minimum, you want to be able to build the 
> module. Directly messing with the sources is usually wrong. I know external 
> module authors like to do that nevertheless; in a few cases it's actually 
> useful. Most of the time it really is not. Most external modules have totally 
> braindead/broken makefiles.
> 

I never said anything about messing with the source.  But anything that
needs access to the running kernel's headers need to know where the
sources are - and that could have been figured out by looking at the
'build' symlink.

Say you maintain an opensource (just to throw out the 'its closed
source, so screw them' arguments) external module that supports both
2.4 and 2.6, and easy way to implement it is to have:

makefile - make will first look for this, and then process it.
           in here you check what kernel is running (via uname -r
           or whatever), and then create the proper 'Makefile'
           symlink, and then call make with arguments to properly
           handle the external module build process for that
           version kernel.

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=

Makefile-2_4 - 100% valid kbuild/whatever Makefile for 2.4 kernels
               (Ok, I am not so sure about how 2.4 handles things
               these days anymore ...)

now the clueless user just calls 'make && make install' and it should
work perfectly.

Or you create an install.sh that does things properly, or whatever,
but point remains that you need to know where the source are ...


Thanks,

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]