Linux – modinfo when a module was compiled into kernel statically wouldn’t work — workarounds

kernel-moduleslinux-kernel

modinfo is rather useful tool when it comes to tweaking module's parameters (at least discovering what options are availalbe), for e. g.:

$ modinfo dummy
filename:       /lib/modules/2.6.32-openvz-042stab102.9-amd64/kernel/drivers/net/dummy.ko
alias:          rtnl-link-dummy
license:        GPL
srcversion:     B2C3F349E2A5175104E1B3E
depends:
vermagic:       2.6.32-openvz-042stab102.9-amd64 SMP mod_unload modversions
parm:           numdummies:Number of dummy pseudo devices (int)

but, not surprisingly, it works only when module wasn't compiled into kernel statically. Any workarounds for getting this or similar info if you, say, have the module compiled in, and have no access to network?

Best Answer

Most or all of the information from modinfo is either just trivia (author, license) or does not apply to built-in modules (magic, depends, filename, etc.).

The only one that has any conceivable practical value is "parm", but again, it cannot apply in the same way to a built-in because you don't load them. The vast majority of modules don't have this anyway. Kernel facilities which can be directly tweaked from userspace usually have an interface in /sys.

What you seem to be asking ("have no access to network" -- i.e., you can't google it) is about documentation. The reason the kernel doesn't regurgitate this "dynamically" is because it isn't dynamic, it's static, and it already exists. The source tree comes with a Documentation directory, and with regard to things like specific licence, author, etc., this static information is also in the source tree. Which you can download and store a local, offline copy of.

For example, parameters for some built-in modules can be set on the kernel command line at boot time. These are listed in Documentation/kernel-parameters.txt (note the documentation tree is reproduced online, so you can see that here).

I realize this is not exactly what you are hoping for, but exactly what you were hoping for would not really be very useful. Again, most of the information is meta-trivial (not relevant to the use of the software); even the name that a module would be given if it were not compiled in is essentially irrelevant. Does it matter if the facilities that provide access to HFS filesystems, if compiled as a loadable module, would be called hfs? There's in fact no information about this that is relevant or meaningful. By analogy, what you are asking for is sort of like wanting to be able to query a running application to find out the names and signatures for various internal function calls -- to the extent that something relating to this might be relevent or meaningful, it should be included organically within documentation.

Related Question