[BusyBox] insmod and multiple versions clarification

[Stewart Brodie]

On Mon May 14 12:08:52 MDT 2001, Erik Andersen wrote:
> On Fri May 11, 2001 at 04:41:28PM -0500, David Douthitt wrote:
> > "Richard A. Smith" wrote:
> > 
> > > My issue was that the pcmcia tools appear to only build modules with
> > > versioning enabled AND busybox insmod was looking for my modules in
> > > the /lib/modules/2.2.17 tree when I was running a 2.2.19 kernel..
> > 
> > >Looking at insmod.c, it looks to me as if insmod does the
> > equivalent of:
> > 
> > find /lib/modules -name "${module}.o"
> > 
> > ...to find modules.  If you had a 2.2.17 dir and a 2.2.19 dir, I
> > wonder if it didn't search 2.2.17 first, so it found those modules
> > instead of those in 2.2.19.

> I just spent a minute adjusting insmod so that it first searches
> /lib/modules/`uname -r` and then (if that fails) searches /lib/modules.
> This should help avoid this type of nasty surprise in the future.

>  -Erik

I dredged this posting up from the archive search as I had a query along
similar lines and Erik's explanation of 2 years ago partly answered it.

The first question I have is why?  This seems a dangerous thing to do.  If
you really want to have some kernel modules which are common to all kernel
versions, then an explicit directory (e.g. /lib/modules/common) would be the
best place to put them.  Anyway, that's really a side issue for me.

I think I need to give a brief overview of what I'm trying to do here and
the consequent problems I am seeing.  I have a single common root filesystem
image which can be stored in the flash of all the different hardware
variants of the product I'm working on. The filesystem doesn't really care
what kernel is running, except for the kernel modules.  Some modules have
customised versions for the particular box type. The script which loads the
modules looks like this, cut down for example:

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

(I know busybox's insmod doesn't support -s yet, but it does silently ignore
it for now, so I've got the option in in case it ever gets implemented)

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?


-- 
Stewart Brodie