linux驱动代码，惠普打印机linux驱动

Linux 内核驱动接口详解

写作本文档的目的，是为了解释为什么Linux既没有二进制内核接口，也没有稳定的内核接口。这里所说的内核接口，是指内核里的接口，而不是内核和用户空间的接口。内核到用户空间的接口，是提供给应用程序使用的系统调用，系统调用在历史上几乎没有过变化，将来也不会有变化。我有一些老应用程序是在0.9版本或者更早版本的内核上编译的，在使用2.6版本内核的Linux发布上依然用得很好。用户和应用程序作者可以将这个接口看成是稳定的。

你也许以为自己想要稳定的内核接口，但是你不清楚你要的实际上不是它。你需要的其实是稳定的驱动程序，而你只有将驱动程序放到公版内核的源代码树里，才有可能达到这个目的。而且这样做还有很多其它好处，正是因为这些好处使得 Linux能成为强壮，稳定，成熟的操作系统，这也是你最开始选择Linux的原因。

只有那些写驱动程序的“怪人”才会担心内核接口的改变，对广大用户来说，既看不到内核接口，也不需要去关心它。

既然只谈技术问题，我们就有了下面两个主题：二进制内核接口和稳定的内核源代码接口。这两个问题是互相关联的，让我们先解决掉二进制接口的问题。

假如我们有一个稳定的内核源代码接口，那么自然而然的，我们就拥有了稳定的二进制接口，是这样的吗？错。让我们看看关于Linux内核的几点事实：

对于一个特定的内核，满足这些条件并不难，使用同一个C编译器和同样的内核配置选项来编译驱动程序模块就可以了。这对于给一个特定Linux发布的特定版本提供驱动程序，是完全可以满足需求的。但是如果你要给不同发布的不同版本都发布一个驱动程序，就需要在每个发布上用不同的内核设置参数都编译一次内核，这简直跟噩梦一样。而且还要注意到，每个Linux发布还提供不同的Linux内核，这些内核都针对不同的硬件类型进行了优化（有很多种不同的处理器，还有不同的内核设置选项）。所以每发布一次驱动程序，都需要提供很多不同版本的内核模块。

相信我，如果你真的要采取这种发布方式，一定会慢慢疯掉，我很久以前就有过深刻的教训…

如果有人不将他的内核驱动程序，放入公版内核的源代码树，而又想让驱动程序一直保持在最新的内核中可用，那么这个话题将会变得没完没了。内核开发是持续而且快节奏的，从来都不会慢下来。内核开发人员在当前接口中找到bug，或者找到更好的实现方式。一旦发现这些，他们就很快会去修改当前的接口。修改接口意味着，函数名可能会改变，结构体可能被扩充或者删减，函数的参数也可能发生改变。一旦接口被修改，内核中使用这些接口的地方需要同时修正，这样才能保证所有的东西继续工作。

举一个例子，内核的USB驱动程序接口在USB子系统的整个生命周期中，至少经历了三次重写。这些重写解决以下问题：

这和一些封闭源代码的操作系统形成鲜明的对比，在那些操作系统上，不得不额外的维护旧的USB接口。这导致了一个可能性，新的开发者依然会不小心使用旧的接口，以不恰当的方式编写代码，进而影响到操作系统的稳定性。在上面的例子中，所有的开发者都同意这些重要的改动，在这样的情况下修改代价很低。如果Linux保持一个稳定的内核源代码接口，那么就得创建一个新的接口；旧的，有问题的接口必须一直维护，给Linux USB开发者带来额外的工作。既然所有的Linux USB驱动的作者都是利用自己的时间工作，那么要求他们去做毫无意义的免费额外工作，是不可能的。安全问题对Linux来说十分重要。一个安全问题被发现，就会在短时间内得到修正。在很多情况下，这将导致Linux内核中的一些接口被重写，以从根本上避免安全问题。一旦接口被重写，所有使用这些接口的驱动程序，必须同时得到修正，以确定安全问题已经得到修复并且不可能在未来还有同样的安全问题。如果内核内部接口不允许改变，那么就不可能修复这样的安全问题，也不可能确认这样的安全问题以后不会发生。开发者一直在清理内核接口。如果一个接口没有人在使用了，它就会被删除。这样可以确保内核尽可能的小，而且所有潜在的接口都会得到尽可能完整的测试（没有人使用的接口是不可能得到良好的测试的）。

如果你写了一个Linux内核驱动，但是它还不在Linux源代码树里，作为一个开发者，你应该怎么做？为每个发布的每个版本提供一个二进制驱动，那简直是一个噩梦，要跟上永远处于变化之中的内核接口，也是一件辛苦活。很简单，让你的驱动进入内核源代码树（要记得我们在谈论的是以GPL许可发行的驱动，如果你的代码不符合GPL，那么祝你好运，你只能自己解决这个问题了，你这个吸血鬼把Andrew和Linus对吸血鬼的定义链接到这里>）。当你的代码加入公版内核源代码树之后，如果一个内核接口改变，你的驱动会直接被修改接口的那个人修改。保证你的驱动永远都可以编译通过，并且一直工作，你几乎不需要做什么事情。

把驱动放到内核源代码树里会有很多的好处：

怎么将驱动源代码编译进linux系统

一、驱动程序编译进内核的步骤

在 linux内核中增加程序需要完成以下三项工作：

1.将编写的源代码复制到 Linux内核源代码的相应目录；

2.在目录的 Kconfig文件中增加新源代码对应项目的编译配置选项；

3.在目录的 Makefile文件中增加对新源代码的编译条目。

bq27501驱动编译到内核中具体步骤如下：

1.先将驱动代码bq27501文件夹复制到 ti-davinci/drivers/目录下。

确定bq27501驱动模块应在内核源代码树中处于何处。

设备驱动程序存放在内核源码树根目录 drivers/的子目录下，在其内部，设备驱动文件进一步按照类别，类型等有序地组织起来。

a.字符设备存在于 drivers/char/目录下

b.块设备存放在 drivers/block/目录下

c. USB设备则存放在 drivers/usb/目录下。

注意：

(1)此处的文件组织规则并非绝对不变，例如： USB设备也属于字符设备，也可以存放在 drivers/usb/目录下。

(2)在 drivers/char/目录下，在该目录下同时存在大量的 C源代码文件和许多其他目录。所有对于仅仅只有一两个源文件的设备驱动程序，可以直接存放在该目录下，但如果驱动程序包含许多源文件和其他辅助文件，那么可以创建一个新子目录。

(3) bq27501的驱动是属于字符设备驱动类别，虽然驱动相关的文件只有两个，但是为了方面查看，将相关文件放在了bq27501的文件夹中。在drivers/char/目录下增加新的设备过程比较简单，但是在drivers/下直接添加新的设备稍微复杂点。所以下面首先给出在drivers/下添加bq27501驱动的过程，然后再简单说明在drivers/char/目录下添加的过程。

2.在/bq27501下面新建一个Makefile文件。向里面添加代码：

obj-$(CONFIG_BQ27501)+=bq27501.o

此时，构建系统运行就将会进入 bq27501/目录下，并且将bq27501.c编译为 bq27501.o

3.在/bq27501下面新建Kconfig文件。添加代码：

menu"bq27501 driver"

config BQ27501

tristate"BQ27501"

default y

---help---

Say'Y' here, it will be compiled into thekernel; If you choose'M', it will be compiled into a module named asbq27501.ko.

endmenu

注意：help中的文字不能加回车符，否则make menuconfig编译的时候会报错。

4.修改/drivers目录下的Kconfig文件，在endmenu之前添加一条语句‘source drivers/bq27501/Kconfig’对于驱动程序，Kconfig通常和源代码处于同一目录。若建立了一个新的目录，而且也希望 Kconfig文件存在于该目录中的话，那么就必须在一个已存在的 Kconfig文件中将它引入，需要用上面的语句将其挂接在 drivers目录中的Kconfig中。

5.修改/drivers目下Makefile文件，添加‘obj-$(CONFIG_BQ27501)+=bq27501/’。这行编译指令告诉模块构建系统在编译模块时需要进入 bq27501/子目录中。此时的驱动程序的编译取决于一个特殊配置 CONFIG_BQ27501配置选项。

6.修改arch/arm目录下的Kconfig文件，在menu"Device Drivers……endmenu"直接添加语句

source"drivers/bq27501/Kconfig"

linux驱动编写过程中遇到的几个问题及解决

1、显示错误：unknown field'ioctl' specified in initializer

解决办法，查看内核include/linux/fs.h文件，发现里边定义的struct file_operations中没有ioctl，这里我们用.unlocked_ioctl取代，形参去掉 struct inode*。

2、在应用程序中，将ioctl替换为unlocked_ioctl后，会出现以下错误：undefined reference to `unlocked_ioctl'。因为系统调用ioctl是没有改变的，还是原来的系统调用接口，只是系统调用的实现中，ioctl()变成了unlocked_ioctl，在应用层你根本不用关注内核中的这些实现上的改变，你只需要按照系统调用的用法用就可以了。所以把应用程序里的unlocked_ioctl改为ioctl，编译，OK，通过。

3、驱动编译完成，在开发板上insmod，出现以下错误：

WARNING: at lib/kobject.c:595 kobject_put+0x50/0x64()

kobject:'扑'(cbc60a00): is not initialized, yet kobject_put() is being called.

---[ end trace da227214a82491b9 ]---

insmod: cannot insert'led_dev.ko': Cannot allocate memory

原来是忘了写内存申请的代码，添加kmalloc和memset。

4、再次insmod，出现下列错误代码：

Unable to handle kernel paging request at virtual address 7f008820

pgd= cbc70000

[7f008820]*pgd=00000000

Internal error: Oops: 5 [#1]

Modules linked in: led_dev(+)

CPU: 0 Tainted: G W(3.0.1#439)

PC is at led_init+0xa8/0x108 [led_dev]

LR is at kobj_map+0x144/0x154

pc: [<bf0020a8>] lr: [<c0246e70>] psr: 60000013

sp: cbc6bf10 ip: cbc6beb0 fp: cbc6bf24

r10: 00000000 r9: bf002000 r8: cbc6a000

r7: 00000000 r6: bf0002bc r5: 00000000 r4: 00000000

r3: 00000000 r2: 00000000 r1: 7f008000 r0: 00000000

Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user

Control: 00c5387d Table: 5bc70008 DAC: 00000015

Process insmod(pid: 112, stack limit= 0xcbc6a268)

Stack:(0xcbc6bf10 to 0xcbc6c000)

bf00: 00000000 c07463c0 cbc6bf7c cbc6bf28

bf20: c00343c8 bf00200c cbc6bf64 cbc6bf38 c0073e24 00000000 00000000 00000000

bf40: 00000000 0000ef52 000d5bf9 bf0002bc 00000000 0000ef52 000d5bf9 bf0002bc

bf60: 00000000 c0034ce8 cbc6a000 00000000 cbc6bfa4 cbc6bf80 c0085960 c0034398

bf80: c00e8738 c00e8610 402004a8 000dfcf8 00000000 00000080 00000000 cbc6bfa8

bfa0: c0034b40 c00858e0 402004a8 000dfcf8 00b5d038 0000ef52 000d5bf9 ffff5f01

bfc0: 402004a8 000dfcf8 00000000 00000080 00000069 00000001 be9c2e64 be9c2e68

bfe0: be9c2e68 be9c2b14 00021cfc 402c1d74 60000010 00b5d038 5fffe821 5fffec21

[<bf0020a8>](led_init+0xa8/0x108 [led_dev]) from [<c00343c8>](do_one_initcall+0x3c/0x188)

[<c00343c8>](do_one_initcall+0x3c/0x188) from [<c0085960>](sys_init_module+0x8c/0x1a4)

[<c0085960>](sys_init_module+0x8c/0x1a4) from [<c0034b40>](ret_fast_syscall+0x0/0x30)

Code: e59f0060 eb52980e ea00000b e59f1058(e5910820)

---[ end trace da227214a82491b9 ]---

Segmentation fault

最后是各种百度，各种谷歌，参考别人的驱动，发现它们的开发板硬件地址并不是自己写的头文件，而是调用mach中已经定义好的头文件，好吧，寻找相应开发板，相应端口的地址头文件，在驱动文件中添加以下头文件：

#include<mach/map.h>

#include<mach/regs-gpio.h>

#include<mach/gpio-bank-m.h>

Ok，打完收工，开发板，测试。运行无阻。完成。

5、在做到DS18B20温度测试模块驱动的时候，看到网上的代码有些函数可以直接对引脚的功能进行设置，比如：s3c2410_gpio_cfgpin(DQ_PIN, DQ_PIN_OUTP);但是对应于我的s3c6410的开发板就不知道用什么函数了，网上找了半天，发现以上函数是在#include<plat/gpio-cfg.h>中，6410中对应的函数为：extern int s3c_gpio_cfgpin(unsigned int pin, unsigned int to);

6、最近学习移植linux内核，移植了新的linux内核以及挂载了新的NFS之后，重新测试led驱动，发现安装模块以后，运行测试程序会出现以下错误：

-/bin/sh:./main: not found（main为主机上编译好的测试程序）

原因：

编译busybox的时候选择了静态编译：

Build Options－>

Build BusyBox as a static binary(no shared libs)

Build with Large File Support(for accessing file>2GB)

如果选择 Build BusyBox as a static binary(no shared libs)方式进行编译时，所需的库已经与程序静态地链接在一起，这些程序不需要额外的库就可以单独运行，但是自己编写的程序在文件系统上运行必须采用静态编译，否则会报诸如：bin/sh: main:not found的错误。

静态编译如：

arm-linux-gcc–static main.c–o main

7.按照普通方法安装配置tftp，并且关闭了防火墙，但是在开发板上tftp主机，总会报错：

tftp: server error:(0) Permission denied

解决办法：

修改文件/etc/sysconfig/selinux，设定其中的

SELINUX=disabled

然后重启电脑即可