Add usage example to the help info

[marklocascio]

In general, kmod is used by creating symlinks with the names of commands. If that is not an option, and kmod needs to be called directly, it is not clear how to pass it the name of the command to use.

For example:

$ /usr/bin/kmod modinfo hid-generic
invalid command 'modinfo'
kmod - Manage kernel modules: list, load, unload, etc
Usage:
        kmod [options] command [command_options]

The way I read the usage example, kmod modinfo hid-generic should be a perfectly fine way to run the modinfo command. How is this intended to work, and can the usage example be updated to be more clear?

[evelikov]

The options listed under "Commands" are the ones accepted. The next ones - lsmod, modinfo, etc... are not.

As the lsmod, modinfo section implies - kmod is monolithic binary, which provides all these extra tools. To use the respective tool, you need to have a symlink (to kmod) with the said name. The kmod install process already creates those symlinks (since v32), alternatively your distro should provide them in their packaging.

For example, my Arch linux box shows:

$ la /usr/bin/{kmod,lsmod,modinfo}
-rwxr-xr-x 1 root root 159K 06.03.2024 08:58 /usr/bin/kmod*
lrwxrwxrwx 1 root root    4 06.03.2024 08:58 /usr/bin/lsmod -> kmod*
lrwxrwxrwx 1 root root    4 06.03.2024 08:58 /usr/bin/modinfo -> kmod*

Above said, can we interest you in writing a patch that makes that clearer? Your perspective should be quite good to distil this in a way that more people can understand.

[marklocascio]

Yes, happy to help. I think all it really needs is a small change to the usage text to make it clearer.

I am curious, though, is there a reason that lsmod, modinfo, modprobe, etc. are not supported as commands?

The use case here is that some newer distributions are compressing kernel modules. I was building out a ramfs with busybox, and busybox's modprobe doesn't currently support compressed kernel modules. It's easy enough to pull the kmod binary into the ramfs, but I didn't want to create symlinks because then there would be one modprobe symlink pointing to busybox and one pointing to kmod. I figured the easier way to go would be to call kmod explicitly with the modprobe argument.

I am also happy to help implement something like that if there is interest. In the short term, I'll make some changes to documentation, and that will at least help clarify.

Thank you!

[lucasdemarchi]

kmod started as a replacement to module-init-tools. At the time we considered that some of the modprobe options and how they were handled were bringing too much baggage (module-init-tools itself replaced modutils, from the 2.4 era kernel, and kept some of that behavior).

Idea was to keep modprobe, insmod, lsmod etc as 99%-compatible with the tools from module-init-tools, and then eventually provide cleaner ones as kmod subcommands. Those new ones would mostly expose the libkmod interface without doing much on top of that - if something more was needed, then it should be implemented in libkmod.

10+ years later, plans didn't materialize and the few tools that had experimental support as kmod subcommands were removed. See dc2440e ("Remove unmaintained experimental tools").

For new tools I think we can still use subcommands. For old ones, with the previous plan scratched, I'm not sure... what to do with kmod lsmod vs kmod list? The first one is also kind of redundant/ugly.

[evelikov]

@marklocascio last time I checked, busybox had some decompression support - don't recall it xz or zlib. Although admittedly, most distros are opting for zstd.

In practise, if you have a compressed initrd, then there's little point in having compressed modules within. The extra compression is unlikely to give you any size savings - quite the opposite. Same logic applies for firmware required by some modules - a feature I added to linux-firmware a while ago and distros are starting to pick up.

I would advise against mixing busybox and kmod (for module handling) in your initrd. In kmod we use text and binary "modules.xxx" files, with the text ones for "ease of reading ... no way used by kmod" (see modules.dep(5). While busybox exclusively use text ones. Mixing the two may work, but it's not something we test.

Also please do your testing before blindly following :-)

@lucasdemarchi don't think I've seen any distros use kmod list, although since code is tiny I guess we can keep it? kmod static-nodes on the other hand is used by Gentoo and Fedora, at least.

[marklocascio]

In practise, if you have a compressed initrd, then there's little point in having compressed modules within. The extra compression is unlikely to give you any size savings - quite the opposite.

I agree, and perhaps your next point is key here. I noticed that in the modules.* text files, modules are indeed referred to by name, including the .zst extension. I create my ramfs by copying files from an existing system, which has its modules compressed. I figured that if I simply decompress the .ko.zst files to .ko and stick them in the ramfs, busybox will fail to parse the modules.* text files because the .ko.zst files won't be present. I briefly considered just running through the modules.* text files and replacing .ko.zst with .ko, but I didn't know what the binary files were for or how to modify those.

So, rather than messing around with the modules.* files and potentially causing some hard-to-debug behaviors, I figured it'd be easier to just plop kmod into the ramfs, and here we are.

If it's possible, I am 100% in favor of simply decompressing the kernel modules from the source and adding them decompressed to my ramfs. If I can confirm that a quick pass through sed will adjust the modules.* text files as needed, then that's the route I'll go.

Thanks for the help! I will still plan to make some small changes to the docs.

[lucasdemarchi]

So, rather than messing around with the modules.* files and potentially causing some hard-to-debug behaviors, I figured it'd be easier to just plop kmod into the ramfs, and here we are.

I'd rather say this should be the sanest thing. And if you have kmod in initramfs, then there's no reason to also have the (simpler) version from busybox.

[lucasdemarchi]

In practise, if you have a compressed initrd, then there's little point in having compressed modules within. The extra compression is unlikely to give you any size savings - quite the opposite. Same logic applies for firmware required by some modules - a feature I added to linux-firmware a while ago and distros are starting to pick up.

I don't actually agree with that. The initramfs being minimal with only the things to boot and switch_root(), it should probably have very few modules. If the initramfs is compressed, you don't save much with the modules being compressed, but we save a lot of space with the rest of the modules in the real root being compressed. And last time I checked it was also faster to load all the modules during boot if they were zstd-compressed. It would be a good exercise to time the module loading in the different scenarios and backing storage.

[lucasdemarchi]

@lucasdemarchi don't think I've seen any distros use kmod list, although since code is tiny I guess we can keep it? kmod static-nodes on the other hand is used by Gentoo and Fedora, at least.

humn ... maybe an improvement would be to allow subcommands and set them to the current tools already implemented. Examples:

kmod list == current behavior of lsmod
kmod insert == current behavior of insmod
kmod probe == current behavior of modprobe (except the -r, see below)
kmod info == current behavior of modinfo
kmod remove == current behavior of modprobe -r
kmod dep == current behavior of depmod

New subcommands should avoid the symlinks (e.g. I'm already thinking of a new kmod bind to bind drivers to devices... I wouldn't add a modbind or the like). Thoughts?

[lucasdemarchi]

depmod we may actually want to move to a separate binary: it has a lot of things that don't belong into libkmod and depmod doesn't make sense in places like initramfs or embedded systems. Guesstimate that the kmod binary would reduce in ~40% by stripping depmod, with combined size not being much more than it currently is.

[evelikov]

Both suggestions look good to me. The only thing I would ask is that we try to get the meson build first... although that's not a blocker.

Quick and dirty test shows closer to 25%, while standalone depmod is 2x the delta:

   text    data     bss     dec     hex filename
 189894    5288     168  195350   2fb16 with/kmod
 137039    4208     152  141399   22857 without/kmod # down by 55k, due to depmod
 118956    2728      96  121780   1dbb4 only-depmod/kmod # 55k from depmod + 65k from the static libkmod/libshared

Edit: add some depmod numbers