[BusyBox] depmod.pl does not report a module with no unresolved symbols in modules.dep

[Bertrand Mollinier Toublet]

Hi,

following an upgrade from Busybox 1.00-pre3 to Busybox 1.00, we suddenly 
could not load a module depending on crc32 any more. A little more 
context: consider Linux 2.4.22 (and up, I guess), the Realtek network 
module as a module (8139too), and the option CRC32 (correctly) not 
selected in the 'Library routines' sub menu of the kernel config.

On the target platform, with a modules.dep produced by the depmod.pl 
script (found under examples in the BusyBox distribution), 'modprobe 
8139too' would complain that module crc32 could not be found (although 
it was correctly present in /lib/modules/linux-2.4.22/kernel/lib). 
Consequently, the 8139too modules could not be loaded as there was 
unresolved symbols that had to do with the crc32 module.

A look into the code of the modprobe applet showed that it would only 
look for modules who had an entry in modules.dep. It then made sense 
that modprobe would not find crc32, as crc32 had no entry in modules.dep.

Since modules.dep was produced with the depmod.pl script, it had to be 
the culprit.

As it turns out, the code of the script is such that it will only output 
to depmod.pl modules which have unresolved symbols in the first place, 
which is not the case of crc32 in Linux 2.4.22.

Question is: are you maintainers interested in a patch for depmod.pl, or 
is this a non-issue?

The fix is summarized by the following diff, but there are a lot more 
issues with the script, which I have worked on as well.

--- depmod.pl   2004-11-09 18:30:51.000000000 -0800
+++ depmod.pl.new       2004-11-09 18:29:55.000000000 -0800
@@ -77,7 +77,6 @@
          $tgtname = "vmlinux";
      } else {
          ($tgtname) = $obj =~ m-(/lib/modules/.*)$-;
-        $dep->{$tgtname}=[];
      }

      warn "MODULE = $tgtname\n" if $verbose;


-- 
Bertrand Mollinier Toublet | Sigma Designs, Inc.
bertrand at sdesigns.com      |     (408) 957 9847