Half-baked ideas: Kernel modules-in-a-file

For more half-baked ideas, see the ideas tag.

The Linux kernel:


5 MB of highly optimized code that runs the world’s computers. You can copy it around and boot it on different hardware.

No wait, that’s all wrong. I’m forgetting about the modules. There are another 2832 files in /lib/modules/3.11.9-200.fc19.x86_64 and without them this kernel will hardly function.

It’s nice to be able to copy the kernel around — to compile it on fast x86-64 and run it on slow ARM, or to run the host kernel in a VM, but all those module files make everyone’s lives a lot more complex.

So my half-baked idea is this:

Combine all the modules into a single file, let’s call it /boot/modules-3.11.9-200.fc19.x86_64. This file might start off as an ext4 filesystem which can be loopback-mounted on /lib/modules. Eventually I’d hope that the module tools could load modules from the file directly.

Now you can happily cross-compile and copy just two kernel files from x86 to ARM or into your VMs, and that’s a lot less hassle.


Filed under Uncategorized

10 responses to “Half-baked ideas: Kernel modules-in-a-file

  1. Forgive my ignorance, but isn’t initrd for this purpose?

    • Josh Boyer

      To a degree. You don’t want your initramfs being a gigabyte in size. Of course, copying around a separate file of that size isn’t really all that great either. Distribution kernels are the worst case scenario here because they build way more than each individual person need for their specific machine.

  2. DDD

    There’s a whole bunch of design decisions in Linux/Unix that are less than simple (initramfs being IMO even more of a pain than the modules masquerading in the userspace library directory). It’d be great if the kernel stuff (Linux only) could be pushed into a separate /boot partition and the userspace (heck isn’t that bit Unix and thus stunningly cross platform and able to run anything without recompiling?) kept isolated from particular kernels.

    On the other hand, all these things have a reason (or at least an excuse)…

  3. Isn’t distribution packaging the sollution? Rpm, deb, tgz.. whatever. Just one or two files you could install on another machine.

    • rich

      No. For supermin we have to copy the modules from /lib/modules (ie. after they are installed). For cross-compiling there’s no easy answer at the moment but distro packaging is essentially irrelevant.

  4. Fortunately, the pioneers of computing came up with a convenient method for combining multiple discrete things into a single, conveniently manipulable item like this. It’s called a ‘directory’, and sure enough, you’ll find all the modules for a given kernel inside one:

    [adamw@adam audio]$ ls -R /lib/modules/3.12.3-1.fc21.x86_64/
    (lots of modules)

    Look! It’s a single object containing all the kernel modules, which you can easily copy around to different places…

    • rich

      It’s not that convenient. Read the post and have a look at the complex code in supermin to see how much complication this causes.

      • Antimoine

        The 9p option works well and saves on disk io.
        libguestfs is sufficiently well-defined that you can use a predefined appliance kernel (I thought that was the point, given your focus on performance), but the depmod-based approach of dracut/initramfs-tools is still available. Dumping the entire directory in the supermin manifest is also an option, and that builds 2-3 files.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.