modprobe woes

Denys Vlasenko vda.linux at googlemail.com
Wed Aug 6 00:50:23 UTC 2008


On Tuesday 05 August 2008 16:02, Timo Teräs wrote:
> Hi all,
> 
> Since my last modprobe patch, I've been figuring out why various other
> things go wrong, and why bb modprobe is still so slow on my old box (0.24s
> vs module-init-tools 0.05s).
> 
> There seems to be two major problems:
> 
> 1. bb modprobe does not support multiple aliases:
> 
> E.g. I'm using ipsec with aes and the current kernel aliases files has:
> alias aes padlock_aes
> alias aes geode_aes
> alias aes aes_generic
> alias aes aes_i586
> 
> And when kernel requests for module "aes", modprobe just ends up trying
> padlock_aes (which won't load on most of my boxes) and errors out.
> 
> module-init-tools tries all the aliased modules in order. Actually,
> preferable would be if it tried the _generic variant last.
> 
> 2. memory hungyness causes slowness
> 
> I tracked down that the slowness is caused because bb modprobe loads all
> config files including aliases (there is *a lot* of them) to memory. The
> seems to slow it down since additional brk() kernel calls needs to be made
> too. And of course using lots of heap is bad for memory limited boxes.

Well, the code sure can be improved, even on a trivial level:

        f = fopen_for_read("/proc/modules");
        if (f == NULL)
                return -1;

        while (fgets(line_buffer, sizeof(line_buffer), f)) {
                char *p;

                p = strchr(line_buffer, ' ');
                if (p) {
                        const char *n;

                        // Truncate buffer at first space and check for matches, with
                        // the idiosyncrasy that _ and - are interchangeable because the
                        // 2.6 kernel does weird things.

                        *p = '\0';
                        for (p = line_buffer, n = name; ; p++, n++) {
                                if (*p != *n) {
                                        if ((*p == '_' || *p == '-') && (*n == '_' || *n == '-'))
                                                continue;
                                        break;
                                }
                                // If we made it to the end, that's a match.
                                if (!*p) {
                                        ret = 1;
                                        goto done;
                                }
                        }
                }
        }

I bet this can be written smaller.

modprobe.c has lots and lots of ungreppable names. Imagine how "easy"
it will be to track usages of names like "mod" (means "module name"!)
and "depend" (means "list of dependencies"). Oh my. "depend" is not even
a noun, its a verb.

> module-init-tools just takes the module name, and parses the files and
> loads only the related stuff (e.g. discards unneeded aliases, but keeps
> all options statements as modprobe can load additional modules; this can
> be done since module-init-tools does not allow dependency to be an alias).
> 
> Also module-init-tools smartly loads only required files; e.g. .symbols
> file is not parsed unless the requested module starts with "symbol:". Etc.
> 
> Btw. module-init-tools also accept "-a" to load multiple modules at
> once, it just re-reads the config files for each requested module.
> 
> 
> Now, I'm writing to ask if I was to make bb modprobe more or less
> module-init-tools alike in these aspects (which would mean pretty big
> changes) would it be accepted in?

Absolutely. "Big" modprobe is meant to be compatible with module-init-tools,
if improving this results in some small growth, it's ok.

> Assuming the size difference is not too 
> big (the new code might end up being smaller since it would require less
> code for memallocs etc.). I can test it well on a 2.6 box. But it might
> also mean no-support for 2.4 unless someone can test it (but I think the
> current support for 2.4 is untested too).

Just pull current svn before you start hacking, I did some slight chnages...
--
vda



More information about the busybox mailing list