Querying Module Information

Additional sources of information are text descriptions that specify the purpose and usage of modules and are stored directly in the binary files. They can be queried using the modinfo tool in the modutils distribution. Various items of data are stored:

□ Author of the driver, usually with an e-mail address. This information is useful, particularly for bug reports (besides granting the developer some personal satisfaction).

□ A brief description of the driver function.

7It is, of course, also necessary to check whether a module is already resident in the kernel — logically, it need not then be added.

□ Configuration parameters that can be passed to the module; possibly with a description of the exact meaning of the parameters.

□ The designation of the device supported (e.g., fd for floppy disk).

□ The license under which the module is distributed.

A separate list is also provided in the module information to accept a list of different device types supported by the driver.

Querying module information using the modinfo tool is not difficult, as the following example shows:

[email protected]> /sbin/modinfo 8139too filename: /lib/modules/2.6.24/kernel/drivers/net/8139too.ko version: 0.9.28

license: GPL

description: RealTek RTL-8139 Fast Ethernet driver author: Jeff Garzik <[email protected]>

srcversion: 1D03CC1F1622811EB8ACD9E

alias: pci:v*d00008139sv000013D1sd0000AB06bc*sc*i*








pci:v000010ECd00008139sv*sd*bc*sc*i* 2.6.24 SMP mod_unload debug:8139too bitmapped message enable number (int) multicast_filter_limit:8139too maximum number of filtered multicast addresses media:8139too: Bits 4+9: force full duplex, bit 5: 100Mbps (array of int) full_duplex:8139too: Force full duplex for board(s) (1) (array of int)

The kernel does not demand that developers supply this information in every module, although this is good programming practice and should be done for new drivers. Many older modules do not provide all the above fields, and developers are generally quite happy to omit detailed descriptions of possible parameters. However, in most cases, there is at least a brief description, the name of the (main) author, and a note on the software license under which the driver is distributed.

How can this additional information be incorporated in the binary module file? In all binary files that use the ELF format (see Appendix E), there are various units that organize the binary data into different categories — technically these are known as sections. To allow information on the module to be added, the kernel introduces a further section named .modinfo. As you will see below, this process is relatively transparent to the module programmer because a set of simple macros is provided to insert the data into the binary file. Naturally, the presence of this additional information does not change the behavior of the code because the .modinfo sections are ignored by all programs that handle modules but are not interested in the information.

Why is information on the module license used stored in the binary file? The reason is not (unfortunately) a technical one but is of a legal nature. Because the kernel source code is covered by the GNU GPL license, there are several legal problems surrounding the use of modules distributed in binary code only. In this respect, the GPL license is somewhat difficult to interpret.8 For this reason, I do not intend to deal with the legal implications here — this is best left to the legal departments of large software manufacturers. It is enough to know that such modules may use only the kernel functions explicitly provided (in contrast, there are also functions that are explicitly provided for GPL-compatible modules only). The standard set

8Some programmers suggest that there are more interpretations of GPL than there are programs distributed under the license.

is perfectly adequate to program standard drivers — if, however, the module wants to delve deeply into the depths of the kernel, it must use other functions, and with some licenses this is prohibited for legal reasons. The modprobe tool must take this situation into consideration when new modules are used. This is why it checks the licenses and rejects illegal link actions.

Most developers (and also users) are not particularly happy about the fact that some manufacturers distribute their drivers in binary modules. This not only makes it difficult to debug kernel errors, but also has an adverse effect on ongoing driver development because it is necessary to rely on manufacturers to eliminate bugs or implement new functions. At this point, it is not my intention to waste your time with the many and varied aspects of manufacturer behavior. I simply refer you to the countless discussions that have taken place, are still taking place, and will doubtless take place in the future on the various Internet channels (not least on the kernel mailing list, see Appendix F).

Continue reading here: Automatic Loading

Was this article helpful?

0 0