kernel 内核模块编译

linux kernel primer：

doit file:

 make -C /source_path/linux-2.6.38 ARCH=arm CROSS_COMP=arm-linux-  SUBDIRS=$PWD modules

 

Makefile file:
obj-m += hellomod.o

 

运行 ./doit 即可

 

 

编译内核时的选项：

 #define TAINT_PROPRIETORY_MODULE	(1<<0)
 #define TAINT_FORCED_MODULE		(1<<1)
 #define TAINT_UNSAFE_SMP		(1<<2)
 #define TAINT_FORCED_RMMOD		(1<<3)

 

 

内核参数：

0097  * Standard types are:
0098  *      byte, short, ushort, int, uint, long, ulong
0099  *      charp: a character pointer
0100  *      bool: a bool, values 0/1, y/n, Y/N.
0101  *      invbool: the above, only sense-reversed (N = true).
0102  */
0103 #define module_param(name, type, perm)                          \
0104         module_param_named(name, name, type, perm)

给内核模块传递参数， 更灵活的控制模块。

0048 /* For every exported symbol, place a struct in the __ksymtab section */
0049 #define __EXPORT_SYMBOL(sym, sec)                               \
0050         extern typeof(sym) sym;                                 \
0051         __CRC_SYMBOL(sym, sec)                                  \
0052         static const char __kstrtab_##sym[]                     \
0053         __attribute__((section("__ksymtab_strings"), aligned(1))) \
0054         = MODULE_SYMBOL_PREFIX #sym;                            \
0055         static const struct kernel_symbol __ksymtab_##sym       \
0056         __used                                                  \
0057         __attribute__((section("___ksymtab" sec "+" #sym), unused))     \
0058         = { (unsigned long)&sym, __kstrtab_##sym }
0059 
0060 #define EXPORT_SYMBOL(sym)                                      \
0061         __EXPORT_SYMBOL(sym, "")
export函数名， 实现功能模块的重用。

内核内存的管理： 为什么使用连续的物理地址

You only need to worry about using physically contiguous memory if the buffer will be accessed by a DMA device on a physically addressed bus (like PCI). The trouble is that many system calls have no way to know whether their buffer will eventually be passed to a DMA device: once you pass the buffer to another kernel subsystem, you really cannot know where it is going to go. Even if the kernel does not use the buffer for DMA today, a future development might do so.

vmalloc的一些限制

vmalloc is often slower than kmalloc, because it may have to remap the buffer space into a virtually contiguous range. kmalloc never remaps, though if not called with GFP_ATOMIC kmalloc can block.

kmalloc is limited in the size of buffer it can provide: 128 KBytes^*). If you need a really big buffer, you have to use vmalloc or some other mechanism like reserving high memory at boot.

^*)This was true of earlier kernels. On recent kernels (I tested this on 2.6.33.2), max size of a single kmalloc is up to 4 MB! (I wrote a fairly detailed post on this.) — kaiwan

转载于:https://www.cnblogs.com/kwingmei/p/3281024.html