#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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
