Linux Loadable Kernel Module HOWTO
5. How To Insert And Remove LKMs
The basic programs for inserting and removing LKMs are insmod and rmmod . See their man pages for details.
Inserting an LKM is conceptually easy: Just type, as superuser, a command like
insmod serial.o
(serial.o contains the device driver for serial ports (UARTs)).
However, I would be misleading you if I said the command just works. It is very common, and rather maddening, for the command to fail either with a message about a module/kernel version mismatch or a pile of unresolved symbols.
If it does work, though, the way to prove to yourself that you know what you're doing is to look at /proc/modules as described in Section 5.5 .
Note that the examples in this section are from Linux 2.4. In Linux 2.6, the technical aspects of loading LKMs are considerably different, and the most visible manifestation of this is that the LKM file has a suffix of ".ko" instead of ".o". From the user point of view, it looks quite similar, though.
Now lets look at a more difficult insertion. If you try
insmod msdos.o
you will probably get a raft of error messages like:
msdos.o: unresolved symbol fat_date_unix2dos
msdos.o: unresolved symbol fat_add_cluster1
msdos.o: unresolved symbol fat_put_super
...
This is because msdos.o contains external symbol references to the symbols mentioned and there are no such symbols exported by the kernel. To prove this, do a
cat /proc/ksyms
to list every symbol that is exported by the kernel (i.e. available for binding to LKMs). You will see that 'fat_date_unix2dos' is nowhere in the list.
(In Linux 2.6, there is no /proc/ksyms . Use /proc/kallsyms instead; the format is like the output of nm : look for symbols labelled "t").
How do you get it into the list? By loading another LKM, one which defines those symbols and exports them. In this case, it is the LKM in the file fat.o . So do
insmod fat.o
and then see that "fat_date_unix2dos" is in /proc/ksyms . Now redo the
insmod msdos.o
and it works. Look at /proc/modules and see that both LKMs are loaded and one depends on the other:
msdos 5632 0 (unused)
fat 30400 0 [msdos]
How did I know fat.o was the module I was missing? Just a little ingenuity. A more robust way to address this problem is to use depmod and modprobe instead of insmod , as discussed below.
When your symbols look like "fat_date_unix2dos_R83fb36a1", the problem may be more complex than just getting prerequisite LKMs loaded. See Section 6 .
When the error message is "kernel/module version mismatch," see Section 6 .
Often, you need to pass parameters to the LKM when you insert it. For example, a device driver wants to know the address and IRQ of the device it is supposed to drive. Or the network driver wants to know how much diagnostic tracing you want it to do. Here is an example of that:
insmod ne.o io=0x300 irq=11
Here, I am loading the device driver for my NE2000-like Ethernet adapter and telling it to drive the Ethernet adapter at IO address 0x300, which generates interrupts on IRQ 11.
There are no standard parameters for LKMs and very few conventions. Each LKM author decides what
5. How To Insert And Remove LKMs
The basic programs for inserting and removing LKMs are insmod and rmmod . See their man pages for details.
Inserting an LKM is conceptually easy: Just type, as superuser, a command like
insmod serial.o
(serial.o contains the device driver for serial ports (UARTs)).
However, I would be misleading you if I said the command just works. It is very common, and rather maddening, for the command to fail either with a message about a module/kernel version mismatch or a pile of unresolved symbols.
If it does work, though, the way to prove to yourself that you know what you're doing is to look at /proc/modules as described in Section 5.5 .
Note that the examples in this section are from Linux 2.4. In Linux 2.6, the technical aspects of loading LKMs are considerably different, and the most visible manifestation of this is that the LKM file has a suffix of ".ko" instead of ".o". From the user point of view, it looks quite similar, though.
Now lets look at a more difficult insertion. If you try
insmod msdos.o
you will probably get a raft of error messages like:
msdos.o: unresolved symbol fat_date_unix2dos
msdos.o: unresolved symbol fat_add_cluster1
msdos.o: unresolved symbol fat_put_super
...
This is because msdos.o contains external symbol references to the symbols mentioned and there are no such symbols exported by the kernel. To prove this, do a
cat /proc/ksyms
to list every symbol that is exported by the kernel (i.e. available for binding to LKMs). You will see that 'fat_date_unix2dos' is nowhere in the list.
(In Linux 2.6, there is no /proc/ksyms . Use /proc/kallsyms instead; the format is like the output of nm : look for symbols labelled "t").
How do you get it into the list? By loading another LKM, one which defines those symbols and exports them. In this case, it is the LKM in the file fat.o . So do
insmod fat.o
and then see that "fat_date_unix2dos" is in /proc/ksyms . Now redo the
insmod msdos.o
and it works. Look at /proc/modules and see that both LKMs are loaded and one depends on the other:
msdos 5632 0 (unused)
fat 30400 0 [msdos]
How did I know fat.o was the module I was missing? Just a little ingenuity. A more robust way to address this problem is to use depmod and modprobe instead of insmod , as discussed below.
When your symbols look like "fat_date_unix2dos_R83fb36a1", the problem may be more complex than just getting prerequisite LKMs loaded. See Section 6 .
When the error message is "kernel/module version mismatch," see Section 6 .
Often, you need to pass parameters to the LKM when you insert it. For example, a device driver wants to know the address and IRQ of the device it is supposed to drive. Or the network driver wants to know how much diagnostic tracing you want it to do. Here is an example of that:
insmod ne.o io=0x300 irq=11
Here, I am loading the device driver for my NE2000-like Ethernet adapter and telling it to drive the Ethernet adapter at IO address 0x300, which generates interrupts on IRQ 11.
There are no standard parameters for LKMs and very few conventions. Each LKM author decides what
No comments:
Post a Comment