[BusyBox] insmod and multiple versions clarification

[Stewart Brodie]

"Andrew Dennison" <andrew.dennison at motec.com.au> wrote:

> Stewart Brodie wrote:

> >
> > hw=`..detect hardware model script..`
> > display=`..detect display type (NTSC, PAL etc.)..`
> >
> > for module in specialchipdriver; do
> >   for prefix in "${hw}-${display}-" "${hw}-" "${display}-" ""; do
> >     insmod 2>/dev/null -s "${prefix}${module}" && break
> >   done
> > done
> >
> > Then I have things under /lib/modules like:
> >
> > 2.4.18/mymods/hw1-specialchipdriver.o 2.4.18/mymods/specialchipdriver.o
> > 2.4.19/mymods/specialchipdriver.o
> >
> > The problem here is that this breaks on "hw1" models when they run a
> > 2.4.19 kernel.  In this case, the specialchipdriver.o module has been
> > adapted to be completely generic and not require a specialist version
> > for hw1 machines any more.
> >
> > Am I correct in believing that as a consequence of this, I *must* enable
> > kernel module versioning in busybox's insmod configuration and that if I
> > do do this, then the insmod of the 2.4.18/mymods/hw1-specialchipdriver.o
> > module will fail properly so that the final iteration of the inner loop
> > loads the 2.4.19 module correctly?

> Why not use busybox modprobe? It'll load dependent modules for you as long
> as you supply a /lib/modules/*/modules.dep for each kernel version that
> describes your dependencies between modules.

We do not have modprobe in our box.  Neither do we have a modules.dep file -
and from a brief look at the source code, the former doesn't do anything
without the latter.

Something in the kernel's build process attempts to run depmod, but it fails
because it (presumably the x86 Linux binary) doesn't understand the MIPS
Linux kernel modules.

It seems that I have to find the modules myself and pass the names directly
to insmod.

> ps: I think "external" modules normally go under /lib/modules/`uname
> -r`/misc/ at least that's where I started putting my custom modules them
> after doing some reading about this a while ago.

Right, I might change our build system to put stuff in there instead then.
One difficulty my build system has is knowing where exactly to install
modules to.  How does it know what `uname -r` is going to be at run-time on
the target?  In the end I wrote a perl script which went into the kernel
source, did "make include/linux/version.h" and extracted the value from the
kernel by preprocessing a file which included version.h and just used the
right macro.  There must be an easier way ...?  I'll re-iterate that it's a
2.4 kernel; from my brief looks at 2.6, building kernel modules seems to be
completely different and requires them to be in the kernel tree, presumably
so this sort of problem no longer arises?

-- 
Stewart Brodie