problems with modprobe on kernel 2.4

[Denys Vlasenko]

On Thursday 12 March 2009 19:12, Timo Teräs wrote:
> Guenter wrote:
> > Hi Timo.
> > Timo Teräs schrieb:
> >> Oh wait, you are on 2.4 kernel. I think the compressed modules work
> >> only on 2.6 atm. This due to the way how the 2.4 module loader works.
> > 
> >> I'd rather not the way, in the above patch. Someone should fix the
> >> 2.4 module loader properly.
> > hmm, you know how things go: kernel updates are more frequently needed
> > than busybox updates, and I guess there's no chance to get changes into
> > 2.4.x kernel nowadays; but tell why you think that something's wrong
> > with the module loader at all? From what I see it works fine with true
> > modprobe, only busybox fails.
> > Anyway, if you say it works with 2.6.x kernel then cant we just enable
> > this freature with a define for 2.4.x too? F.e. something like:
> > #define CONFIG_FEATURE_MODPROBE_USE_GZIPPED_MODULES
> 
> There's a big difference how module loading works in 2.4 vs 2.6.
> In 2.4 the modutils must load the kernel object, relocate it, and
> do all symbol fixups. Basically, the insmod works as linker in 2.4.
> 
> In 2.6, there is a kernel syscall: you just pass on a binary blob
> loaded from disk to kernel and it'll do all the magic.
> 
> Now, the busybox insmod/modprobe for 2.6 is smart and can load
> .gz files. However, the 2.4 module loader is old code,

Yes. For example, noticing something wrong here?

        m_name = xstrdup(bb_basename(m_filename));
        *strrchr(m_name, '.') = 0;

I just tested. It does segfault.

> and does 
> not load the whole file; instead it tries to load only the parts
> of the file it needs. This makes changing the code to use the
> "smart API for .gz files" trickier. No one has had interest to
> do it yet.

But it does not look to be _too_ hard. bb_init_module_24()
is an entry point to 2.4 module loading. It opens a file.
Then file descriptor gets passed _only_ to obj_load()
and obj_load_progbits(). Those only ever seek and read from it.

By replacing "int fd" param with "void *image, size_t image_size"
pair and passing it instead, we can work on in-memory images.
Unpacking and reading of .gz modules is _extremely_ easy too:

size_t len = MAXINT(ssize_t);
void *image = xmalloc_open_zipped_read_close(filename, &len);

That's it.

Care to make it work, Guenter?

(If you do, fetch svn tree, in older trees it was using
FILE-based i/o, for no good reason)

--
vda