1.insmod makes an init_module system call to load LKM into kernel memory.
2.This is confusing -- every LKM has a subroutine named init_module, and the base kernel has a system call by that same name, which is accessible via a subroutine in the standard C library also named init_module
3.If you want to see the kind of information insmod can get from a query_module system call, look at the contents of /proc/ksyms(In 2.6 use /proc/kallsyms instead).
4. Note that some LKMs call subroutines in other LKMs. They can do this because of the __ksymtab and .kstrtab sections in the LKM object files.
in 2.6 use __ksymtab_strings section instead of .kstrtab
These sections together list the external symbols within the LKM object file that are supposed to be accessible by other LKMs inserted in the future.
insmod looks at __ksymtab and .kstrtab and tells the kernel to add those symbols to its exported kernel symbols table.
To see this for yourself, insert the LKM msdos.o and then notice in /proc/kallsyms the symbol fat_add_cluster (which is the name of a subroutine in the fat.o LKM). Any subsequently inserted LKM can branch to fat_add_cluster, and in fact msdos.o does just that.
5.List all modules
cat /proc/modules
6. There are may have dependency relationship between two modules, for example, module fat.o and module msdos.o
msdos.o will call subroutine in module fat.o, if fat.o not to inserted, msdos.o insert will falied.
How to know module dependency?
Use modprobe instead of insmod(modprobe intelligent find dependency)
7.How to fill insmod parameters
LKM author decides what parameters insmod will take for his LKM, You will find them documented in the doucumentation of the LKM.
Every Module has itself Parameter, for example, mcd module has parameter mcd
8.LKM ELF object file
(1)Section .modinfo, insmod uses the .modinfo section for following:
It contains the kernel release number for which the module was built. I.e. of the kernel source tree whose header files were used in compiling the module.
insmod uses that information as explained in Section 6.
It describes the form of the LKM's parameters. insmod uses this information to format the parameters you supply on the insmod command line into data structure initial values, which insmod inserts into the LKM as it loads it.
(2)To see the sections of an object file, including the .modinfo section if it exists, use the objdump program. For example:
To see all the sections in the object file for the msdos LKM:
objdump msdos.o --section-headers
To see the contents of the .modinfo section:
objdump msdos.o --full-contents --section=.modinfo
2.This is confusing -- every LKM has a subroutine named init_module, and the base kernel has a system call by that same name, which is accessible via a subroutine in the standard C library also named init_module
3.If you want to see the kind of information insmod can get from a query_module system call, look at the contents of /proc/ksyms(In 2.6 use /proc/kallsyms instead).
4. Note that some LKMs call subroutines in other LKMs. They can do this because of the __ksymtab and .kstrtab sections in the LKM object files.
in 2.6 use __ksymtab_strings section instead of .kstrtab
These sections together list the external symbols within the LKM object file that are supposed to be accessible by other LKMs inserted in the future.
insmod looks at __ksymtab and .kstrtab and tells the kernel to add those symbols to its exported kernel symbols table.
To see this for yourself, insert the LKM msdos.o and then notice in /proc/kallsyms the symbol fat_add_cluster (which is the name of a subroutine in the fat.o LKM). Any subsequently inserted LKM can branch to fat_add_cluster, and in fact msdos.o does just that.
5.List all modules
cat /proc/modules
6. There are may have dependency relationship between two modules, for example, module fat.o and module msdos.o
msdos.o will call subroutine in module fat.o, if fat.o not to inserted, msdos.o insert will falied.
How to know module dependency?
Use modprobe instead of insmod(modprobe intelligent find dependency)
7.How to fill insmod parameters
LKM author decides what parameters insmod will take for his LKM, You will find them documented in the doucumentation of the LKM.
Every Module has itself Parameter, for example, mcd module has parameter mcd
8.LKM ELF object file
(1)Section .modinfo, insmod uses the .modinfo section for following:
It contains the kernel release number for which the module was built. I.e. of the kernel source tree whose header files were used in compiling the module.
insmod uses that information as explained in Section 6.
It describes the form of the LKM's parameters. insmod uses this information to format the parameters you supply on the insmod command line into data structure initial values, which insmod inserts into the LKM as it loads it.
(2)To see the sections of an object file, including the .modinfo section if it exists, use the objdump program. For example:
To see all the sections in the object file for the msdos LKM:
objdump msdos.o --section-headers
To see the contents of the .modinfo section:
objdump msdos.o --full-contents --section=.modinfo