1 静态编译驱动进内核
当我们编写完一个驱动后，我们要把它以模块形式编译或者直接编译进内核时，需要修改相关文件，其中最重要的便是kconfig ,makefile。
主要是分析一下三者之间的关系，然后就其语法简要的谈一下。
当我们在内核源码目录下执行make命令时，实际上是根据makefile 来进行编译的。
在mini2440开发板上编写了一个按键控制led灯的驱动。文件名为buttons_leds.c属于字符驱动，把buttons_leds.c加入/driver/char/目录下，然后在/driver/char/目录下的makefile部分最后添加一行
obj-$(CONFIG_BUTTONS_LEDS) += buttons_leds.o
如下：
obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o tty_port.o
obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o
obj-$(CONFIG_CONSOLE_TRANSLATIONS) += consolemap.o consolemap_deftbl.o
obj-$(CONFIG_HW_CONSOLE) += vt.o defkeymap.o
obj-$(CONFIG_AUDIT) += tty_audit.o
obj-$(CONFIG_BUTTONS_LEDS) += buttons_leds.o
其中第一行obj-y 中的y表示编译进内核，而obj-$(CONFIG_BUTTONS_LEDS) 中CONFIG_BUTTONS_LEDS则表示一个变量，类似于我们C语言中的变量，用$( )来表示，它一般可以取三种值y ,m ,n。y表示编译进内核，而m则表示以模块的方式进行编译，n表示不编译进内核。obj-y += 等号后面的.o后缀文件则是由该目录下的对应名称的.c文件编译而来。
上面CONFIG_BUTTONS_LEDS变量的取值则是通过.config文件来集中赋值的。
.config部分内容如下
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_DEVKMEM is not set
CONFIG_MINI2440_HELLO_MODULE=m
CONFIG_BUTTONS_LEDS=m
CONFIG_LEDS_MINI2440=m
CONFIG_MINI2440_BUTTONS=m
CONFIG_MINI2440_BUZZER=y
CONFIG_MINI2440_ADC=y
# CONFIG_SERIAL_NONSTANDARD is not set
从上面几行我们可以看到，在makefile里面的变量都是在.config中赋值的。当我们在源代码目录下输入make命令时，都是默认从.config中读入。
当我们在内核源码目录下输入make menuconfig时，出现如下内容：
.config - Linux Kernel v2.6.32.2 Configuration
──────────────────────────────────────────────
┌──────────Linux Kernel Configuration────────────────────┐
│ Arrow keys navigate the menu. selects submenus --->. Highlighted letters are hotkeys. Pressing includes, excludes, modularizes features. Press to exit, > for Help, > for Search. Legend: [*] built-in [ ] excluded module < > module capable
│ ┌───────────────────────────────────────────┐
│ │ General setup ---> │
│ │ [*] Enable loadable module support ---> │
│ │ -*- Enable the block layer ---> │
│ │ System Type ---> │
│ │ Bus support ---> │
│ │ Kernel Features ---> │
│ │ Boot options ---> │
│ │ CPU Power Management ---> │
│ │ Floating point emulation ---> │
│ │ Userspace binary formats ---> │
│ │ Power management options ---> │
│ │ [*] Networking support ---> │
│ │ Device Drivers ---> │
│ │ File systems ---> │
│ └─────────┴(+)───────────────────────────────│
├────────────────────────────────────────────┤
│ < Exit > < Help > │
└────────────────────────────────────────────┘
它是通过读取在内核源码目录下的Kconfig文件来配置的。
在/drivers/char/下的目录kconfig部分内容如下：
config DEVKMEM
bool "/dev/kmem virtual device support"
default y
help
Say Y here if you want to support the /dev/kmem device. The
/dev/kmem device is rarely used, but can be used for certain
kind of kernel debugging operations.
When in doubt, say "N".
config MINI2440_HELLO_MODULE
tristate "Mini2440 module sample"
depends on MACH_MINI2440
default m if MACH_MINI2440
help
Mini2440 module sample.
config BUTTONS_LEDS
tristate "Mini2440 button and leds sample"(Mini2440 button and leds sample是显示在make menuconfig对话框中)
depends on MACH_MINI2440
default m if MACH_MINI2440
help
Mini2440 button and leds module sample.
其具体语法格式说明如下：
config关键字是一个新的配置选项的入口，其后的选项BUTTONS_LEDS 省略了CONFIG。完整的表示为CONFIG_BUTTONS_LEDS,也即是当我们将该选项设置成y时，它将自动的将 .config的CONFIG_BUTTONS_LEDS=m改写成CONFIG_BUTTONS_LEDS=y。
紧接着的是菜单的属性最主要的有2种tristate ,boolean 。
tristate表示三态：编译进内核(y)，编译成模块(m)，不编译(n)。
boolean 主要有两种y或n。
depend则表示依赖项。
default缺省的编译选项，m表示默认该文件表示以模块方式编译。
随着操作系统升级，编译选项达到几千个。对于一般人来说，要搞清每一个选项是很困难的，一般很多选项都是默认的。
其中.config文件可以手动修改
总的来说，三者之间的关系如下：当我们在内核源码目录下输入make menuconfig时(从kconfig文件里面读)，在出现的菜单界面中选择一项时，它会自动更新.config相应项的值。如果我们没有选择，则会在.config问下插入一行注释。类似于# CONFIG_SERIAL_NONSTANDARD is not set，当我们输入make时，根据makefile文件来编译，makefile文件中的变量值则由.config来进行赋值操作。仅仅只在kconfig中添加选项，只会在菜单界面中显示，即使此时选择y或m，也不会编译文件。还需要在makefile文件中按照规定添加相应行才能进行编译。简单图解如下：
(make menuconfig)kconfig--->.config--->(make)makefile
2 下面以动态为例子:
一个驱动分为应用层(这里目的为测试)和底层。
底层：
第一步：
任意在系统里面建立一个文件夹(在用户目录下/home/litingting/)
指令:mkdir /tmp/led
第二步：
在已经建立的文件夹led里面编写两个文档，一个是Makefile,一个是ledled.c。
指令：echo 'obj-m:=ledled.o' > Makefile
解释：
Makefile作用就是定义ledled.c的编译规则。
Makefile编写：obj-m:=led.o，表示C文件被编译成模块，为后面动态加载做准备ledled.c编写：这是我们学习的最重要部分Linux驱动有自己的一套规则，一个驱动在linux中被当成一个文件，文件相关的函数主要是write,open之类的，至于程序的编写系统基本给我们固定了了一个模型，我们编写就是按这个模型完成里面的功能函数.
第三步：
编译ledled.c文件，把编译好生成的驱动加到开发板上运行，开发板的内核版本为3.0.8，所以我们编译这个函数肯定要在相同版本内核下编译，编译过程要用到相应版本的内头文件，编译完后会在led文件夹里面生成很多文件，我们要的就是那个ledled.ko文件。
指令：make -C /home/litingting/linux-3.0.8 M=/tmp/led
(这一步之前可能要编译内核，先执行make然后执行
cp mini210_android_defconfig .config，这里碰到时再说)
第四步：
用优盘拷走ledled.ko文件插到开发板上，启动开发板。
第五步：
连好串口线，在电脑终端输入sudominicom，进入开发板系统(优盘会自动挂载到开发板系统的udisk文件下)，进入该文件夹就可以看到那个.ko文件，之后输入insmodledled.ko(表示把驱动加入开发板内核)。
之后执行：ls -a /dev(可以查看到这个驱动)
ls -l /dev(可以查看到系统自动为这个驱动分配的主设备号和从设备号)
到此，正常的话驱动已经被烧入内核。
第六步：
建立设备文件(也叫设备节点)，系统最终以打开文件的方式来调用驱动，所以肯定得为驱动建立一个与该驱动对应的设备文件，这里取设备名为ledledo。
mknod /dev/ledledo c 10 42
c:代表该驱动为字符类型驱动(这种驱动最基础，也是我们主要研究的)
10：代表主设备号
42：从设备号(这两个设备号在第五步里面得到)
到此，底层部分已经完成。
应用层：
第七步：编写应用层，取名为ledledapp.c(里面肯定有一条指令时打开驱动的指令),编好后用交叉编译器编译，生成可执行文件，然后用优盘拷走，插到开发板上，打开开发板，打开udisk，就能看到可执行文件ledledapp,执行文件指令为./ledledapp
到此，一个完整的linux驱动例子完成
编译应用程序指令：arm-linux-gcc -static-o hello hello.c有时需要静态编译才能运行
我主要碰到的两个问题：
一个是交叉编译器的使用：
用arm-linux-gcc-static -o hello hello.或者
用arm-linux-gcchello.c -o hello来交叉编译c文件，生成的文件可在arm上运行。
另外一个是：
一定要把开发板一样的内核移动到linux系统的文件夹里面，我的在D盘里面，我怎么编译都不能成功，后来我把这个内核文件夹移到linux本身系统里面，就可以了，问题就是D盘文件格式和linux系统里面的文件格式不一样。
469
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
