[BusyBox] insmod and multiple versions clarification

[Andrew Dennison]

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.

Andrew

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.

> -----Original Message-----
> From: busybox-bounces at mail.busybox.net
> [mailto:busybox-bounces at mail.busybox.net]On Behalf Of Stewart Brodie
> Sent: Monday, 17 November 2003 11:43 PM
> To: busybox at mail.busybox.net
> Subject: [BusyBox] insmod and multiple versions clarification
>
>
> 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
> _______________________________________________
> busybox mailing list
> busybox at mail.busybox.net
> http://busybox.net/mailman/listinfo/busybox
>