Month: February 2017

输入设备都有共性:中断驱动+字符IO，基于分层的思想，Linux内核将这些设备的公有的部分提取出来，基于cdev提供接口，设计了输入子系统，所有使用输入子系统构建的设备都使用主设备号13，同时输入子系统也支持自动创建设备文件，这些文件采用阻塞的IO读写方式，被创建在“/dev/input/”下。如下图所示。内核中的输入子系统自底向上分为设备驱动层，输入核心层，事件处理层。由于每种输入的设备上报的事件都各有不同，所以为了应用层能够很好识别上报的事件，内核中也为应用层封装了标准的接口来描述一个事件，这些接口在“/include/upai/linux/input”中。

• 设备驱动层是具体硬件相关的实现，也是驱动开发中主要完成的部分，
• 输入核心层主要提供一些API供设备驱动层调用，通过这些API设备驱动层上报的数据就可以传递到事件处理层，
• 事件处理层负责创建设备文件以及将上报的事件传递到用户空间，

具体的，这三个层次每一个层次都由一条结构体链表组成，在设备驱动层，核心结构体是input_dev;在input核心层，是input_handle;在事件处理层，是input_handler。内核通过链表和指针将三者结合到一起，最终实现了input_dev和input_handler的多对多的映射关系，这种关系可用下图简单描述:

• 

input对象描述了一个输入设备，包括它可能上报的事件，这些事件使用位图来描述，内核提供的相应的工具帮助我们构建一个input对象，大家可以参考内核文档“Documentation/input/input-programming.txt”，里面对于input子系统的使用有详细的描述。

Continue reading →

软件上的定时器最终要依靠硬件时钟来实现，简单的说，内核会在时钟中断发生后检测各个注册到内核的定时器是否到期，如果到期，就回调相应的注册函数，将其作为中断底半部来执行。实际上，时钟中断处理程序会触发TIMER_SOFTIRQ软中断，运行当前处理器上到期的所有定时器。
设备驱动程序如要获得时间信息以及需要定时服务，都可以使用内核定时器。

要说内核定时器，首先就得说说内核中关于时间的一个重要的概念:jiffies变量，作为内核时钟的基础，jiffies每隔一个固定的时间就会增加1,称为增加一个节拍，这个固定间隔由定时器中断来实现，每秒中产生多少个定时器中断，由在<linux/param.h>中定义的HZ宏来确定，如此，可以通过jiffies获取一段时间，比如jiffies/HZ表示自系统启动的秒数。下两秒就是(jiffies/HZ+2),内核中用jiffies来计时，秒转换成的jiffies:seconds*HZ，所以以jiffiy为单位，以当前时刻为基准计时2秒:(jiffies/HZ+2)*HZ=jiffies+2*HZ如果要获取当前时间，可以使用do_gettimeofday()，该函数填充一个struct timeval结构，有着接近微妙的分辨率。

//kernel/time/timekeeping.c
 473 /**
 474  * do_gettimeofday - Returns the time of day in a timeval
 475  * @tv:         pointer to the timeval to be set
 476  *
 477  * NOTE: Users should be converted to using getnstimeofday()
 478  */
 479 void do_gettimeofday(struct timeval *tv)   

驱动程序为了让硬件有足够的时间完成一些任务，常常需要将特定的代码延后一段时间来执行，根据延时的长短，内核开发中使用长延时和短延时两个概念。长延时的定义为：延时时间>多个jiffies，实现长延时可以用查询jiffies的方法：

time_before(jiffies, new_jiffies);
time_after(new_jiffiesmjiffies);

**短延时的定义为：延迟事件接近或短于一个jiffy，实现短延时可以调用

udelay();
mdelay();

这两个函数都是忙等待函数，大量消耗CPU时间，前者使用软件循环来延迟指定数目的微妙数，后者使用前者的嵌套来实现毫秒级的延时。

timer_list

Continue reading →

等待队列是内核中实现进程调度的一个十分重要的数据结构，其任务是维护一个链表，链表中每一个节点都是一个PCB(进程控制块)，内核会将PCB挂在等待队列中的所有进程都调度为睡眠状态，直到某个唤醒的条件发生，本文主要讨论驱动中怎么实现对设备IO的阻塞与非阻塞读写。显然，实现这种与阻塞相关的机制要用到等待队列机制。本文的内核源码使用的是3.14.0版本

设备阻塞IO的实现

当我们读写设备文件的IO时，最终会回调驱动中相应的接口，而这些接口也会出现在读写设备进程的进程(内核)空间中，如果条件不满足，接口函数使进程进入睡眠状态，即使读写设备的用户进程进入了睡眠，也就是我们常说的发生了阻塞。In a word，读写设备文件阻塞的本质是驱动在驱动中实现对设备文件的阻塞，其读写的流程可概括如下:

1. 定义-初始化等待队列头

//定义等待队列头
wait_queue_head_t waitq_h;
//初始化，等待队列头
init_waitqueue_head(wait_queue_head_t *q);
 //或
//定义并初始化等待队列头
DECLARE_WAIT_QUEUE_HEAD(waitq_name);

上面的几条选择中，最后一种会直接定义并初始化一个等待头,但是如果在模块内使用全局变量传参，用着并不方便，具体用哪种看需求。
我们可以追一下源码，看一下上面这几行都干了什么：

//include/linux/wait.h 
 35 struct __wait_queue_head { 
 36         spinlock_t              lock;
 37         struct list_head        task_list;
 38 };
 39 typedef struct __wait_queue_head wait_queue_head_t;

–36–>这个队列用的自旋锁
–27–>将整个队列”串”在一起的纽带

然后我们看一下初始化的宏:

 55 #define __WAIT_QUEUE_HEAD_INITIALIZER(name) {                           \
 56         .lock           = __SPIN_LOCK_UNLOCKED(name.lock),              \
 57         .task_list      = { &(name).task_list, &(name).task_list } }
 58 
 59 #define DECLARE_WAIT_QUEUE_HEAD(name) \
 60         wait_queue_head_t name = __WAIT_QUEUE_HEAD_INITIALIZER(name)

–60–>根据传入的字符串name，创建一个名为name的等待队列头
–57–>初始化上述task_list域，竟然没有用内核标准的初始化宏，无语。。。

2. 将本进程添加到等待队列

为等待队列添加事件,即进程进入睡眠状态直到condition为真才返回。_interruptible的版本版本表示睡眠可中断,_timeout版本表示超时版本，超时就会返回，这种命名规范在内核API中随处可见。

Continue reading →

异步通知的全称是”信号驱动的异步IO”，通过”信号”的方式，放期望获取的资源可用时，驱动会主动通知指定的应用程序，和应用层的”信号”相对应，这里使用的是信号”SIGIO“。操作步骤是

1. 应用层程序将自己注册为接收来自设备文件的SIGIO信号的进程
2. 驱动实现相应的接口，以期具有向所有注册接收这个设备驱动SIGIO信号的应用程序发SIGIO信号的能力。
3. 驱动在适当的位置调用发送函数，应用程序即可接收到SIGIO信号。

整个机制的框架：

• 

应用层接收SIGIO

和其他信号一样，应用层需要注册一个信号处理函数，
注册的方式还是使用signal()或sigaction()

此外，应用层还需要把自己加入到驱动的通知链表中，加入的代码如下

fcntl(dev_fd,F_SETOWN,getpid());
int oflags = fcntl(dev_fd,F_GETFL);
fcntl(dev_fd，F_SETFL，oflags|FASYNC);
...
while(1);

完成了上面的工作，应用层的程序就可以静待SIGIO的到来了。

驱动发送SIGIO

Continue reading →

下图是Linux的内存映射模型

1. 每一个进程都有自己的进程空间，进程空间的0-3G是用户空间，3G-4G是内核空间
2. 每个进程的用户空间不在同一个物理内存页，但是所有的进程的内核空间对应同样的物理地址
3. vmalloc分配的地址可以高端内存，也可以是低端内存
4. 0-896MB的物理地址是线性映射到物理映射区的。
5. 内核参数和系统页表都在TEXT_OFFSET保存，除了进程除了访问自身的用户空间对应的DRAM内存页外，都要经过内核空间，也就是都要切换到内核态

• 

内存动态申请

和应用层一样，内核程序也需要动态的分配内存，不同的是，内核进程可以控制分配的内存是在用户空间还是内核空间，前者可以用于给用户空间的堆区分配内存，eg，用户进程的用户空间的malloc最终就会通过系统调用回调内核空间的内存分配函数，此时该内存分配函数就属于该用户进程，可以给在该用户进程的堆区分配空间并返回，最终使得一个用会进程在自己的用户空间获得内存分配;后者只在内核空间分配，所以用户进程不能直接访问该空间，所以多用在满足内核程序自身的内存需求，下面是Linux内核空间申请内存常用API：

kmalloc – kfree

kmalloc申请的内存在物理内存上是连续的，他们与真实的物理地址只有一个固定的偏移，因此存在简单的转换关系。这个API 多用来申请不到一个page大小的内存。kmalloc的底层需要调用__get_free_pages，参数中表示内存类型的gtp_t flags正是这个函数的缩写，常用的内存类型有GFP_USER,GFP_KERNEL,GFP_ATOMIC几种。

• GFP_USER表示为用户空间页分配内存，可以阻塞;
• GFP_KERNEL是最常用的flag，注意，使用这个flag来申请内存时，如果暂时不能满足，会引起进程阻塞，So，一定不要在中断处理函数，tasklet和内核定时器等非进程上下文中使用GFP_KERNEL！！！
• GFP_ATOMIC就可以用于上述三种情境,这个flag表示如果申请的内存不能用，则立即返回。

Continue reading →