[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Suggestions for module-assistant improvement



#include <hallo.h>
* Jurij Smakov [Sun, Apr 02 2006, 11:49:19AM]:
> Hi Eduard,
> 
> Since we are planning to use module-assistant as a recommended tool for 
> building OOT modules, I went through the code and found a few things which 

Okay, let me see. IIRC: originaly I invented the beast for end-users and
SOHO admins and only later I've added features for creating officially
looking DEB packages with .changes file generation. That feature is not
regularly used/tested by me but seemed to work as expected the last time
I used it.

> can be done better, in my opinion. The list is below and comments are 
> welcome. I'm willing to produce the patches for these issues, if there are 
> no strong objections.
> 
> 1. Default path to kernel modules set by m-a (KSRC) is /usr/src/linux. I 

Well, the first search path is /usr/src/linux but it double-checks the
version of the headers therein before using it. Generally it goes through this list
and checks version.h:

foreach $poskdir ("$usrc/linux", "$usrc/$kheaders-$my_kvers", <$usrc/*>,
</usr/local/src/*>, "/lib/modules/".$my_kvers."/build",
<$opt_userdir/usr_src/*>)

> think that if it is not set externally, it makes more sense to look for 
> the configured source in /lib/modules/$(uname -r)/{build, source} and

"source" symlink is new to me. Does it have precedence to "build"?

> use /usr/src/linux as a fallback if those don't exist. In the official 
> kernels the build symlink will point to the correct linux-headers dir in 
> /usr/src.

I just mentally played trough possible use cases and assumed worst case
scenarios. I cannot see a good case where the change would hurt. So I
will change it. The new order is: ("/lib/modules/".$my_kvers."/source",
"/lib/modules/".$my_kvers."/build", <$opt_userdir/usr_src/*>,
"$usrc/linux", "$usrc/$kheaders-$my_kvers", <$usrc/*>,
</usr/local/src/*>) - any objections?

> 2. If not set, KVERS is determined by parsing the header files in the 
> source. This is not very robust. I strongly suggest to invoke
> 'make kernelrelease' in the kernel source tree to determine the 
> version for which it was configured. 2.6.16 also has the kernelversion
> target which return only the version triplet, without the extra stuff.
> The failure of this command will also indicate the the source tree we are 
> using is broken/unconfigured.

As said on IRC, this is kernel 2.6 only. And it won't help to detect a
broken or just partial header tree, see:

/usr/src/linux-headers-2.6.16-rc6-686$ make kernelrelease 
Makefile:1311: *** kernelrelease not valid - run 'make *config' to update it.  Schluss.

IMO the same game, version.h is missing and everything breaks.

> 3. There is some ad hoc magic present to map the Debian arch to the kernel 
> arch (which is currently implemented only for sparc). I think a more 
> scalable way is to make a helper script, which would do it correctly for 
> all arches.

Very good idea. I have implemented such hacks on request only, because
of having no useable experience with cross-compiling.

> 4. DEB_DEST_DIR (the place where the generated debs are placed) 
> should probably always be $(CURDIR)/.. .

Nack. If you wish to force a location, set KPKG_DEST_DIR as described in
the manpage.

Eduard.



Reply to: