Linux 字符设备驱动 II

前文中已经简单的介绍了字符设备驱动的基本的编程框架,这里我们来探讨一下Linux内核(以4.8.5内核为例)是怎么管理字符设备的,即当我们获得了设备号,分配了cdev结构,注册了驱动的操作方法集,最后进行cdev_add()的时候,究竟是将哪些内容告诉了内核,内核又是怎么管理我的cdev结构的,这就是本文要讨论的内容。我们知道,Linux内核对设备的管理是基于kobject的,这点从我们的cdev结构中就可以看出,所以,接下来,你将看到”fs/char_dev.c”中实现的操作字符设备的函数都是基于“lib/kobject.c”以及“drivers/base/map.c”中对kobject操作的函数。好,现在从cdev_add()开始一层层的扒。

cdev_map对象

内核中关于字符设备的操作函数的实现放在“fs/char_dev.c”中,打开这个文件,首先注意到就是这个在内核中不常见的静态全局变量cdev_map(27),我们知道,为了提高软件的内聚性,Linux内核在设计的时候尽量避免使用全局变量作为函数间数据传递的方式,而建议多使用形参列表,而这个结构体变量在这个文件中到处被使用,所以它应该是描述了系统中所有字符设备的某种信息,带着这样的想法,我们可以在“drivers/base/map.c”中找到kobj_map结构的定义:

从中可以看出,kobj_map的核心就是一个struct probe类型、大小为255的数组,而在这个probe结构中,第一个成员next(21)显然是将这些probe结构通过链表的形式连接起来,dev_t类型的成员dev显然是设备号,get(25)和lock(26)分别是两个函数接口,最后的重点来了,void作为C语言中的万金油类型,在这里就是我们cdev结构(通过后面的分析可以看出),所以,这个cdev_map是一个struct kobj_map类型的指针,其中包含着一个struct probe*类型、大小为255的数组,数组的每个元素指向的一个probe结构封装了一个设备号和相应的设备对象(这里就是cdev),下图中体现两种常见的对设备号和cdev管理的方式,其一是一个cdev对象对应这一个/多个设备号的情况, 在cdev_map中, 一个probes对象就对应一个主设备号,多个设备号对应一个cdev时,其实只是次设备号在变,主设备号还是一样的,所以是同一个probes对象;其二是当主设备号超过255时,会进行probe复用,此时probe->next就派上了用场,比如probe[200],可以表示设备号200,455…3895等所有对255取余是200的数字, 参见下文的kobj_map–58–。

cdev_add()

了解了cdev_map的功能,我们就可以一探cdev_add()。从中可以看出,其工作显然是交给了kobj_map()


–460–>就是将我们之前获得设备号和设备号长度填充到cdev结构中,
–468–>kobject_get()将kobject的计数减一,并返回struct kobject*

Continue reading

Linux 字符设备驱动 I

字符设备就是字节流形式通讯的I/O设备, 是Linux三大设备之一, 日常所见的绝大部分设备都是字符设备,包括鼠标、键盘、显示器、串口等等,当我们执行ls -l /dev的时候,就能看到大量的设备文件,c就是字符设备,b就是块设备,网络设备没有对应的设备文件。编写一个外部模块的字符设备驱动,除了要实现编写一个模块所需要的代码之外,还需要编写作为一个字符设备的代码。

Linux一切皆文件,那么作为一个设备文件,它的操作方法接口封装在struct file_operations,当我们写一个驱动的时候,一定要实现相应的接口,这样才能使这个驱动可用,Linux的内核中大量使用”注册+回调”机制进行驱动程序的编写,所谓注册回调,简单的理解,就是当我们open一个设备文件的时候,其实是通过VFS找到相应的inode,并执行此前创建这个设备文件时注册在inode中的open函数,其他函数也是如此,所以,为了让我们写的驱动能够正常的被应用程序操作,首先要做的就是实现相应的方法,然后再创建相应的设备文件。

Continue reading

Linux 内核模块编程框架

Linux是单内核系统,可通用计算平台的外围设备是频繁变化的,不可能将所有的(包括将来即将出现的)设备的驱动程序都一次性编译进内核,为了解决这个问题,Linux提出了可加载内核模块(Loadable Kernel Module,LKM)的概念,允许一个设备驱动通过模块加载的方式,在内核运行起来之后”融入”内核,加载进内核的模块和本身就编译进内核的模块一模一样, 这个内核模块被称之为Kernel Object, ko。
一个程序在编译的地址的相对关系就已经确定了,运行的时候只是进行简单的偏移,为了使模块加载进内核后能够被放置在正确的地址,并正确的调用系统的运行的导出符号表,编译模块的时候必须要使用系统的编译地址,并调用系统编译出得静态的导出符号表。即模块必须使用系统的配置环境:Makefile+.config,一旦这两个文件任意一个发生了变化,都很可能导致模块的编译地址与系统的编译地址不匹配,造成运行时的错误甚至宕机。

内核模块原理

从提供系统运行效率的角度,一个模块不是也不应该是完全独立的,即一个模块往往会调用其他模块提供的功能来实现自己的功能,这样做能更好实现系统的分工并提高效率。Linux为了实现模块间的相互调用,设计了导出符号表,每个模块都可以将自己的一个私有的标号导出到系统层级,以使该标号对其他模块可见,系统在编译一个模块的时候会自动导出这个模块的导出符号表到modules.syms文件(如果没有导出任何符号,可以为空),并在加载一个模块的时候会自动将该模块的导出符号表与系统自身的导出符号表合并。一个系统的源码的导出符号表一般在源码顶层目录的modules.syms文件中,查看正在运行的系统导出符号表使用cat /proc/kallsyms。注意,正如前面解释的,我们的模块之所以能够正常运行,一个重要原因就是编译我们模块使用的符号地址就是编译内核时使用的符号地址,所以运行起来虽然地址会有偏移,但是模块中相关的符号的地址也会和内核地址一起偏移,也就还能找得到。基于这种思想,我们也可以直接查看系统当前运行的地址,将地址赋值给一个函数指针并使用,也是没有问题的,当然,这只是阐述原理,并不建议这么写模块。
下面这个例子可以看出编译出的地址和运行时的地址是不一样的:

导出符号表可以大大的提高系统的运行效率,这也是只有开源系统才能提供的一个强大的功能,但是,导出符号表的引入会导致一个小小的麻烦–模块的依赖,当我们使用lsmod的时候,就可以查看系统当前的模块,其最后两列分别是该模块被引用的次数以及引用该模块的内核模块,当一个模块被其他模块引用时,我们是不能进行卸载的,同样,如果模块A依赖于模块B,那么如果模块B不加载的时候模块A也加载不了。在编写多模块的时候尤其要注意这个问题,可以写一个脚本管理多个依赖模块。Linux内核使用两个宏来导出一个模块的符号:

Continue reading

Linux 设备树 III

本文主要介绍内核中提供的操作设备树的API,这些API通常都在“include/of.h”中声明。

device_node

–47–>节点名
–48–>设备类型
–50–>全路径节点名
–54–>父节点指针
–55–>子节点指针

Continue reading

Linux 设备树 II

设备树就是为驱动服务的,配置好设备树之后还需要配置相应的驱动才能检测配置是否正确。比如dm9000网卡,就需要首先将示例信息挂接到我们的板级设备树上,并根据芯片手册和电路原理图将相应的属性进行配置,再配置相应的驱动。需要注意的是,dm9000的地址线一般是接在片选线上的,所以设备树中就应该归属与相应片选线节点,我这里用的exynos4412,接在了bank1,所以是“<0x50000000 0x2 0x50000004 0x2>”
最终的配置结果是:

勾选相应的选项将dm9000的驱动编译进内核。

执行make uImage;make dtbs,tftp下载,成功加载nfs根文件系统并进入系统,表示网卡移植成功

Linux 设备树 I

Linux内核从3.x开始引入设备树的概念,用于实现驱动代码与设备信息相分离。在设备树出现以前,所有关于设备的具体信息都要写在驱动里,一旦外围设备变化,驱动代码就要重写。引入了设备树之后,驱动代码只负责处理驱动的逻辑,而关于设备的具体信息存放到设备树文件中,这样,如果只是硬件接口信息的变化而没有驱动逻辑的变化,驱动开发者只需要修改设备树文件信息,不需要改写驱动代码。比如在ARM Linux内,一个.dts(device tree source)文件对应一个ARM的machine,一般放置在内核的“arch/arm/boot/dts/”目录内,比如exynos4412参考板的板级设备树文件就是“arch/arm/boot/dts/exynos4412-origen.dts”。这个文件可以通过$make dtbs命令编译成二进制的.dtb文件供内核驱动使用。

基于同样的软件分层设计的思想,由于一个SoC可能对应多个machine,如果每个machine的设备树都写成一个完全独立的.dts文件,那么势必相当一些.dts文件有重复的部分,为了解决这个问题,Linux设备树目录把一个SoC公用的部分或者多个machine共同的部分提炼为相应的.dtsi文件。这样每个.dts就只有自己差异的部分,公有的部分只需要“include”相应的.dtsi文件, 这样就是整个设备树的管理更加有序。我这里用Linux4.8.5源码自带的dm9000网卡为例来分析设备树的使用和移植。这个网卡的设备树节点信息在"Documentation/devicetree/bindings/net/davicom-dm9000.txt"有详细说明,其网卡驱动源码是"drivers/net/ethernet/davicom/dm9000.c"

Continue reading