Month: December 2016

前文中已经简单的介绍了字符设备驱动的基本的编程框架，这里我们来探讨一下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
 27 static struct kobj_map *cdev_map;

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

//drivers/base/map.c
 19 struct kobj_map {     
 20         struct probe {
 21                 struct probe *next;
 22                 dev_t dev;
 23                 unsigned long range;
 24                 struct module *owner;
 25                 kobj_probe_t *get;
 26                 int (*lock)(dev_t, void *);
 27                 void *data;
 28         } *probes[255];  
 29         struct mutex *lock;
 30 };

从中可以看出，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 →

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

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

#include <linux/cdev.h> //for struct cdev
#include <linux/fs.h>   //for struct file
#include <asm-generic/uaccess.h>    //for copy_to_user
#include <linux/errno.h>            //for error number

static int ma = 0;
static int mi = 0;
const int count = 3;

/* 准备操作方法集 */
/* 
struct file_operations {
    struct module *owner;   //THIS_MODULE
    
    //读设备
    ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
    //写设备
    ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);

    //映射内核空间到用户空间
    int (*mmap) (struct file *, struct vm_area_struct *);

    //读写设备参数、读设备状态、控制设备
    long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);

    //打开设备
    int (*open) (struct inode *, struct file *);
    //关闭设备
    int (*release) (struct inode *, struct file *);

    //刷新设备
    int (*flush) (struct file *, fl_owner_t id);

    //文件定位
    loff_t (*llseek) (struct file *, loff_t, int);

    //异步通知
    int (*fasync) (int, struct file *, int);
    //POLL机制
    unsigned int (*poll) (struct file *, struct poll_table_struct *);
    。。。
};
*/

ssize_t myread(struct file *filep, char __user * user_buf, size_t size, loff_t* offset)
{
    return 0;
}

struct file fops = {
    .owner = THIS_MODULE,
    .read = myread，
    ...
};

/* 字符设备对象类型 
struct cdev {
    struct kobject kobj;     
    struct module *owner;        //模块所有者（THIS_MODULE），用于模块计数
    const struct file_operations *ops;    //操作方法集（分工:打开、关闭、读/写、...）
    struct list_head list;
    dev_t dev;                            //设备号（第一个）
    unsigned int count;            //设备数量
};
*/

static int __init chrdev_init(void)
{
    ...
    /* 构造cdev设备对象 */
    struct cdev *cdev_alloc(void);

    /* 初始化cdev设备对象 */
    void cdev_init(struct cdev*, const struct file_opeartions*);

    /* 申请设备号，静态or动态*/
    /* 为字符设备静态申请第一个设备号 */
    int register_chrdev_region(dev_t from, unsigned count, const char* name);

    /* 为字符设备动态申请第一个设备号 */
    int alloc_chrdev_region(dev_t* dev, unsigned baseminor, unsigned count, const char* name);

    ma = MAJOR(dev)     //从dev_t数据中得到主设备号
    mi = MINOR(dev)     //从dev_t数据中得到次设备号
    MKDEV(ma,1) //将主设备号和次设备号组合成设备号,多用于批量创建/删除设备文件

    /* 注册字符设备对象cdev到内核 */
    int cdev_add(struct cdev* , dev_t, unsigned);
    ...
}

static void __exit chrdev_exit(void)
{
    ...
    /* cdev_del()、cdev_put()二选一 */
    /* 从内核注销cdev设备对象 */
    void cdev_del(struct cdev* );

    /* 从内核注销cdev设备对象 */
    void cdev_put(stuct cdev *);

    /* 回收设备号 */
    void unregister_chrdev_region(dev_t from, unsigned count);
    ...
}

Continue reading →

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内核使用两个宏来导出一个模块的符号:

EXPORT_SYMBOL(符号名)
EXPORT_SYMBOL_GPL(符号名)

Continue reading →

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

device_node

//include/of.h
 46 struct device_node {
 47         const char *name;
 48         const char *type;
 49         phandle phandle;
 50         const char *full_name;
 51 
 52         struct  property *properties;
 53         struct  property *deadprops;    /* removed properties */
 54         struct  device_node *parent;
 55         struct  device_node *child;
 56         struct  device_node *sibling;
 57         struct  device_node *next;      /* next device of same type */
 58         struct  device_node *allnext;   /* next in list of all nodes */
 59         struct  proc_dir_entry *pde;    /* this node's proc directory */
 60         struct  kref kref;
 61         unsigned long _flags;
 62         void    *data;
 63 #if defined(CONFIG_SPARC)
 64         const char *path_component_name;
 65         unsigned int unique_id;
 66         struct of_irq_controller *irq_trans;
 67 #endif
 68 };

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

Continue reading →

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

• 

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

make menuconfig
[*] Networking support  --->
    Networking options  --->
        <*> Packet socket
        <*>Unix domain sockets 
        [*] TCP/IP networking
        [*]   IP: kernel level autoconfiguration
Device Drivers  --->
    [*] Network device support  --->
        [*]   Ethernet driver support (NEW)  --->
            <*>   DM9000 support
File systems  --->
    [*] Network File Systems (NEW)  --->
        <*>   NFS client support
        [*]     NFS client support for NFS version 3
        [*]       NFS client support for the NFSv3 ACL protocol extension
        [*]   Root file system on NFS

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

• 

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 →