Re: [PATCH 0/2] kbuild updates

[Andreas Gruenbacher <agruen@suse.de>]

On Monday 21 June 2004 02:29, Hannu Savolainen wrote:
> On Mon, 21 Jun 2004, Sam Ravnborg wrote:
> > > Many external modules, libs, etc use
> > > /lib/modules/`uname -r`/build to locate the _source_, and this will
> > > break them all.
> >
> > Examples please. What I have seen so far is modules that was not
> > adapted to use kbuild when being build.
> > If they fail to do so they are inherently broken.
>
> For example our installation script expects that
> /lib/modules/`uname -r`/build behaves like a symbolic link that points to
> /usr/src/linux-`uname -r`. If /lib/modules/`uname -r`/build doesn't exist
> then /usr/src/linux-`uname -r` will be attempted instead.
>
> "make -C $KERNELDIR SUBDIRS=$MYDIR \
>       CC=what_we_think_is_the_right_gcc_version" modules
>
> This approach seems to work with the "stock" kernels as well as with all
> the distribution kernels what we have tried so far (except the latest
> kernel from SuSE that used different directory scheme).

Did you actually try the above command with a SUSE kernel? I don't think so; 
one of the earlier postings in the other thread spiced with strong words 
tried to do other unusual things.

> It's relatively easy to use the dual directory scheme provided that the
> object and source directories always have the same naming. However it's
> possible that in the future there will be much more projects that need to
> compile external modules. So it would be easier in general if the
> (possible) dual directory scheme is "hidden" from the external projects.

This is already in place with Sam's patches.

> It should be easy difficult to patch the Makefile in
> /lib/modules/`uname -r`/build to locate the object directory without
> requiring the caller to pass it as a parameter to the "make modules"
> command.

There is one source tree for N object trees in general. Going from the N side 
to the 1 side makes a lot more sense than going the other way around.

> There is one special problem that doesn't affect users who have compiled
> their kernel themselves. Many distributions don't include gcc, make and
> related tools in the default installation so large amount of customer
> sites don't have them installed.

You will invoke make directly, so you should check if make and the kernel 
sources for the running kernel are available.

> In addition different gcc version may 
> have to be used to compile the kernel than the one that is the default gcc
> command in the system.

Then this should be defined in the Makefile in the kernel sources. Fixing 
problems for people who build their own kernels from vanilla sources without 
paying attention to such details will take you nowhere, it will only mess 
things up even worse.

> So before anything can be compiled the installation 
> scripts have to check also if the required tools are installed. If they
> are not available then the customer needs to be instructed to install
> them. Because the installation procedure depents on the distribution it's
> very difficult to help the customer in any way. For this reason it would
> be better if the re is some kind of unbrella script for building the
> module. In the vanilla kernels it simply executes the right make command.
> If the distribution vendors see it necessary they can improve the script
> and add features like automatic installation of the required modules or
> whatever else.

There could be a few basic checks in kbuild whether or not the required tools 
are available. Telling users who compile kernel modules on their own how to 
install packages sounds a bit much asked for my taste.

Regards,
-- 
Andreas Gruenbacher <agruen@suse.de>
SUSE Labs, SUSE LINUX AG