3

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?

  • 1
    Afaik, you can only list the params and get their current value (see my post here). If your distro ships the kernel together with the docs you might find some additional info there related to possible params values. – don_crissti Feb 17 '15 at 15:30
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.