字符设备是指必须以字节流顺序访问的设备，如字符终端( /dev/console )、串口( /dev/tty* )、触摸屏、磁带驱动器、鼠标等。

• 其驱动程序至少需要实现 open 、 close 、 read 、 write 系统调用。
• 字符设备可以通过文件系统节点来访问(通常在 /dev 下)。
• 字符设备可以使用 open() 、 read() 、 write() 等方式进行访问。

块设备允许按照任意顺序进行访问，以块为单位进行操作，如硬盘、eMMC等。

• 块设备有两种访问方式：
  1. 使用类似于 dd 的命令操作设备的块
  2. 在块设备上建立 FAT 、 EXT4 等文件系统后，使用文件系统的方式进行访问。
• 块设备也可以通过文件系统节点来访问(通常在 /dev 下)。
• 块设备可以使用 open() 、 read() 、 write() 等方式进行访问。

网络设备面向数据包的发送和接收设计，内核与网络设备之间的通信主要使用Socket。

• 一个纯软件实现的网络设备的例子为回环接口( loopback )。
• 网络设备并不是面向流的设备，因此通常不会被映射到Linux文件系统的文件和目录上，通常会被分配一个唯一的名字，如 eth0 。
• 网络设备会使用另外一套操作函数而不是 read() 、 write() 等。

当前的通用处理器主要采用了冯诺依曼架构和哈佛架构两种架构形式，其对应的常见的CPU系列有：

• 冯诺依曼架构：Intel、ARM7、MIPS
• 哈佛架构：AVR、ARM9-11、Arm Cortex A
  具体区别可见常见CPU架构及其对比。

• arch：与体系结构相关的代码
• crypto：

static int __init init_func(void)
{
	// 具体实现...
	// 初始化成功时应当返回0
	// 执行失败时应当选择 <linux/errno.h> 中的错误代码
}
// 指定初始化函数
module_init(init_func);
复制

注意：

• 模块的加载函数中通常会遇到错误，在遇到错误后，应当停止后续的加载并释放已经加载的内存。在这里通常使用 goto 语句实现，也可以编写统一的 cleanup 函数检查资源是否被成功分配并释放资源(推荐后者)。一般 cleanup 函数不会被注册为卸载函数，因此不能被标记为 __exit 。
• 错误码应当使用 <linux/errno.h> 中的错误码，这样方便用户使用 perror 之类的函数将错误转换为有意义的字符串。

static void __exit exit_function(void)
{
	// ...模块卸载，释放资源
}
// 指定模块卸载函数
module_exit(exit_function);
复制

如果未定义模块卸载函数，则内核不允许卸载该模块。

模块在加载时可以传入一些命令行参数，其主要通过如下方式进行定义与加载：

// 相当于缺省参数
static int port = 8080;
// module_param(name, type, perm)
module_param(port, int, S_IRUGO);
复制

在 module_param 函数中：

• perm 为访问许可配置：
  • S_IRUGO 表示任何人都可以读取该参数
  • S_IRUGO|S_IWUSR 表示root用户可以修改该参数。但是当参数发生修改时，内核不会通知内核模块参数被修改，因此通常不使用。

在加载时可以通过如下命令指定模块参数：

insmod var=value #例如：insmod port=80
复制

内核模块支持的加载参数列表如下：

• bool
• invbool ：关联int型，反转bool值，输入为 true 则传入为 false 。
• charp ：关联char*，内核会为用户提供的字符串分配内存并设置指针。
• int
• long
• short
• uint ：关联unsigned int，u表示无符号。
• ulong
• ushort
• 及上述类型对应的数组形式，使用 module_param_array 进行参数接收。

int add_int(int a, int b)
{
	return a + b;
}
// 导出符号
EXPORT_SYMBOL(add_int);

int add_int_gpl(int a, int b)
{
	return a + b;
}
// 导出包含GPL许可证的符号
EXPORT_SYMBOL_GPL(add_int);
复制

注意：使用 EXPORT_SYMBOL_GPL 导出的符号不可以被非GPL模块引用。

模块许可证声明：

MODULE_LICENSE("GPL v2");
复制

模块作者信息：

MODULE_AUTHOR("xxtech");
复制

模块描述：

MODULE_DESCRIPTION("...");
复制

模块版本：

MODULE_VERSION("V1.0");
复制

模块别名：

MODULE_ALIAS("...");
复制

1. 定义只在初始化阶段就需要的数据：

static int var_name __initdata = 0;
复制

上述 __initdata 和模块加载函数的 __init 都标识在内核被加载完毕后，其所定义的变量或函数会被从内存中扔掉。
2. 与上一条相似的是，内核中也有 __exitdata 与 __exit 。上述四个特性均会被放置到特殊ELF端。

在为内核编写模块时，一定要选择与目标系统相匹配的内核源码，否则生成的模块无法使用。

当内核模块 test_module.ko 由多个源文件 file1.c 、 file2.c 、 ... 构成时，Makefile中可以如下编写：

obj-m += test_module.o
module-objs += file1.o file2.o ...
复制

用户态驱动的优点：

1. 可以链接整个C语言库甚至非标准库。内核中无法使用完整的C语言库。
2. 可以使用普通的gdb等调试器调试驱动程序，而不是像内核模块一样printk。
3. 用户态驱动发生问题通常不会影响系统稳定性。
4. 用户态驱动程序可以换出，当驱动程序不使用时可以换出到硬盘。
5. 方便用户规避GPL协议，方便实现闭源驱动。
6. 用户态驱动已经可以实现大多数设备驱动所需，且有一些被广泛应用的用户态驱动，例如 libusb 等。同时可以先在用户态完成大部分驱动开发与调试，随后移植到内核态。

用户态驱动的缺点：

1. 用户态驱动不可使用中断。但是部分架构上有对应的解决方案，例如IA32的 vm86 。
2. 只有通过 mmap 映射 /dev/mem 才可以直接访问物理内存，但是需要对应权限(不一定需要root，可以配置访问权限)。
3. 只有使用 ioperm 或 ioctl 才可以访问IO端口，但是并非所有平台都有此支持，性能较差且需要对应权限。
4. 响应速度慢，内核直接与硬件交互，但是用户态需要切换内核态，切换上下文后才可以与硬件交互。
5. 一旦用户态驱动被换出磁盘，其响应速度会极其慢。使用特权用户的 mlock 或许可以缓解，但是用户态驱动通常会链接多个库，需要占用多个page。
6. 用户空间无法完成重要设备的驱动，例如网络设备和块设备。

静态分配需要指定主设备号，主设备号的选择可以查看 Documentation/admin-guide/devices.txt 中的示例。
静态分配设备号的前提是要知道哪些设备号可用，再去指定想要申请的设备号。
查询空闲设备号需要读取 /proc/devices 文件未使用的设备号。
其主要的API有如下两个

// 该函数会从from下的从设备号作为起始从设备号，向from所指的主设备下连续申请count个设备
int register_chrdev_region(dev_t from, unsigned count, const char *name)
复制

// 该函数会在指定的主设备号下注册一个从设备，此时要求主设备号大于0。
// 设备信息为该函数的第二、三个参数。
// 在此种用法下，函数的成功返回值为0，失败为负值。
// 该函数也可以用于动态分配设备号，见下一章节。
static inline int register_chrdev(unsigned int major, const char *name,
								 const struct file_operations *fops)
复制

上述函数的 struct file_operations 用于建立文件操作和驱动程序操作的连接。具体可见绑定文件操作章节。

动态分配不需要指定主设备号，根据 Documentation/admin-guide/devices.txt 中的说明，对于字符设备而言，动态分配的主设备号会从254开始向下分配直到234，分配完毕后再从511开始向下分配直到384。

为了考虑驱动在多台设备上的兼容性，避免冲突，应当优先考虑动态分配设备号。

// 该函数会从baseminor开始，向dev所指主设备下连续注册count个设备
// baseminor通常为0
int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count,
			const char *name)
复制

// 该函数会自动，此时要求主设备号等于0。
// 设备信息为该函数的第二、三个参数。
// 在此种用法下，函数的成功返回值为0，失败为负值。
// 该函数也可以用于动态分配设备号，见下一章节。
static inline int register_chrdev(unsigned int major, const char *name,
								 const struct file_operations *fops)
复制

对于上述的所有分配设备编号的方法，均可以使用如下的函数进行释放：

void unregister_chrdev_region(dev_t from, unsigned count)
复制

read方法的返回值应符合如下几种情况：

1. 当返回值大于0时，其含义为从字符设备读取到的字节数，该值不能大于 count 。
   1. 当返回值等于 count 时表示读取成功。
   2. 当返回值小于 count 时，在部分情况下程序可能会重复执行read直到凑够 count ，例如使用标准库的 fread 读取设备文件就会自动执行此流程。
2. 当返回值为0时，表示读取到文件末尾。
3. 当返回值小于0时，其用于表示错误。错误值定义于 <linux/errno.h>
   此外，read方法也可以实现阻塞读取方式。

write和read方法的返回值及其注意事项相似。

普通信号量的动态初始化可以用如下的函数进行：

void sema_init(struct semaphore *sem, int val);
复制

该函数中的 val 为该信号量的初始值。

互斥锁可以按照如下的方式使用静态定义：

#include <asm/semaphore.h>

// 定义初始值为1的互斥量，即mutex
DECLARE_MUTEX(name);
// 定义初始值为0的互斥量，在获取该互斥量之前必须先显式的解锁
DECLARE_MUTEX_LOCK(name);
复制

由于该宏的实际用途为定义，但命名却使用了 DECLARE ，因此在Linux 2.6.36之后就删除了该接口。

同样的，Linux也提供了互斥锁动态初始化的方法：

void init_MUTEX(struct semaphore *sem);
void init_MUTEX_LOCKED(struct semaphore *sem);
复制

不过这两个函数也在之后的版本被移除。

互斥锁本质就是信号量的增加与减少。互斥锁的减少可以使用如下的函数：

void down(struct semaphore *sem);
int down_interruptible(struct semaphore *sem);
int down_trylock(struct semaphore *sem);
复制

函数 down 会阻塞等待直至成功获取到对应的互斥量，且该操作不允许被用户空间中断。
函数 down_interruptible 也会互斥等待，但是允许等待该信号量的操作被用户空间程序中断。在其因用户空间的程序中断的时候该函数的返回值为非零值，且此时内核程序并未获得该互斥量。
函数 down_trylock 则永远不会休眠，成功获得互斥资源时返回值为0，其他情况为非0。

互斥资源操作时，在非必要情况下应当使用允许中断的版本。
注意上述的中断指的是可否被用户中断，而不是可否被阻塞休眠。不可休眠的是自旋锁。

互斥锁的增加直接使用如下函数即可：

void up(struct semaphore *sem);
复制

读写锁与普通的信号量有些不同，因此其需要使用头文件 <linux/rwsem.h> ，其初始化方法与操作方法如下：

void init_rwsem(struct rw_semaphore *sem);

// 读者API
void down_read(struct rw_semaphore *sem);
int down_read_trylock(struct rw_semaphore *sem);
void up_read(struct rw_semaphore *sem);

// 写者API
void down_write(struct rw_semaphore *sem);
int down_write_trylock(struct rw_semaphore *sem);
void up_write(struct rw_semaphore *sem);
void downgrade_write(struct rw_semaphore *sem);
复制

其中， downgrade_write 是将写者降级为读者。

在内核编程时常用的一个设计方法是在别的线程初始化某个活动，原线程会等待该活动结束后才会继续执行后续任务。尽管使用信号量就可以解决这个需求，但是内核也提供了更好的解决方案，即completion接口，头文件为 <linux/completion.h> ，用法如下：

// 静态初始化
DECLARE_COMPLETION(my_completion);

// 动态初始化
struct completion my_completion;
init_completion(&my_completion);
复制

随后可以如下使用：

void wait_for_completion(struct completion *c);
void complete(struct completion *c);
void complete_all(struct completion *c);
复制

在用户态，自旋锁主要用于避免快速上锁/释放锁的场景下线程进入阻塞状态后，因调度算法导致进程再次获得处理机所需要的较长时间。而无论内核态还是用户态，自旋锁是都用于避免被阻塞休眠的。在内核中，有些工作不能进入阻塞状态，例如中断处理程序等。
自旋锁的头文件位于 <linux/spinlock.h> ，用法如下：

// 静态初始化
spinlock_t lock = SPIN_LOCK_UNLOCKED;

// 动态初始化
void spin_lock_init(spinlock_t *lock);
复制

自旋锁只是在申请和等待锁时不会被休眠，但是自旋锁并不负责保护临界区代码不会被休眠。并且在使用自旋锁时应当避免代码被休眠，否则极有可能引发死锁并引起内核崩溃，例如在中断服务函数中使用了一个自旋锁，但是该锁被其他进程持有，且该进程被中断服务抢占CPU时间，导致中断永远无法结束，进程也永远无法获得CPU时间从而导致死锁。

但是避免休眠很难做到，例如：

• 使用常见的可能休眠的函数导致休眠
  • copy_form_user
  • kmalloc
• 被高优先级进程抢占处理器时间
• 触发处理器中断
  等，因此需要做如下的额外处理：

1. 避免使用任何的可能导致休眠的函数
2. 使用自旋锁时应当关闭中断
3. 尽可能的减少持有该锁的时间

因此自旋锁的操作除了如下的两个基础API：

void spin_lock(spinlock_t *lock);
void spin_unlock(spinlock_t *lock);
复制

以外，还有相较高级一些的API：

// 获得自旋锁的函数
void spin_lock_irqsave(spinlock_t *lock, unsigned long long flags);
void spin_lock_irq(spinlock_t *lock);
void spin_lock_bh(spinlock_t *lock);

// 释放自旋锁的函数
void spin_unlock_irqsave(spinlock_t *lock, unsigned long long flags);
void spin_unlock_irq(spinlock_t *lock);
void spin_unlock_bh(spinlock_t *lock);
复制

其中：

• spin_lock_irqsave 会在获得自旋锁之前禁止中断，先前的状态会被保存于 flags 中。该函数是宏函数，因此 flags 会被修改。其本质调用为 flags = _raw_spin_lock_irqsave(lock);
• spin_lock_irq 和上述函数的实际调用一致，只是忽略了需要保存的 flags 。
• spin_lock_bh 会关闭所有软件中断，但不会关闭硬中断。
• spin_unlock_irqsave 可以将由 spin_lock_irqsave 保存的 flags 恢复。

还有非阻塞式的函数：

int spin_trylock(spinlock_t *lock);
int spin_trylock_bh(spinlock_t *lock);
复制

上述函数在成功获得自旋锁时会返回0，其他情况为非0。

自旋读写锁的头文件依旧位于 <linux/spinlock.h> ，其常用方法如下：

// 静态初始化
rwlock_t lock = RE_LOCK_UNLOCKED;

// 动态初始化
rwlock_t lock;
rwlock_init(&lock);
复制

void read_lock(rwlock_t *lock);
void read_lock_irqsave(rwlock_t *lock, unsigned long flags);
void read_lock_irq(rwlock_t *lock);
void read_lock_bh(rwlock_t *lock);
复制

void read_unlock(rwlock_t *lock);
void read_unlock_irqsave(rwlock_t *lock, unsigned long flags);
void read_unlock_irq(rwlock_t *lock);
void read_unlock_bh(rwlock_t *lock);
复制

void write_lock(rwlock_t *lock);
void write_lock_irqsave(rwlock_t *lock, unsigned long flags);
void write_lock_irq(rwlock_t *lock);
void write_lock_bh(rwlock_t *lock);
int write_trylock(rwlock_t *lock);
复制

void write_unlock(rwlock_t *lock);
void write_unlock_irqsave(rwlock_t *lock, unsigned long flags);
void write_unlock_irq(rwlock_t *lock);
void write_unlock_bh(rwlock_t *lock);
复制

在编写代码时，很容易会写出一个已经持有互斥锁的函数去调用另外一个需要持有互斥锁才能运行的函数，这种通常称为递归调用。而在上述给出的并发管理工具中并未给出类似于POSIX中的递归锁或可重入锁，因此在内核编程中应更加着重注意此类问题。通常的做法是在所有暴露给内核的API中做互斥管理，然后在这些API中所调用的内部实现均假设该互斥资源已被占有。

一个API需要同时获取多个互斥资源是一个很常见的事情，且非常容易触发操作系统中的类似于哲学家吃饭问题的死锁问题，通常的处理方式是一个内核程序统一按照一个有序的方式申请资源(即资源的有序分配法)。
并且，需要注意的是，在同时应当获得一个信号量和一个自旋锁时，必须优先获取信号量，随后再去申请自旋锁。因为持有自旋锁的进程被信号量阻塞是一件严重错误且非常危险的事情。
当然，最好的处理此类需要获取多个互斥资源的方法就是尽量避免这种现象。

关于互斥资源管理的粒度问题，可以直接以Linux对SMP的支持进行举例。
在第一个支持多处理器的Linux2.0，整个内核有且仅有一个巨大的临界区(BKL，Big Kernel Lock)。当需要操作内核临界区时都需要申请该互斥锁。而在后来的Linux2.2中，互斥锁管理的粒度逐渐细化，例如I/O子系统共用一个互斥锁，网络系统共用一个互斥锁等。到了现在的版本，Linux内核中已经拥有了上千个互斥锁。
互斥资源管理粒度的细化无疑会提升CPU资源的利用率，但是在实际的工程中，不应当过早的细化互斥资源的管理，因为项目最终的性能瓶颈往往不会出现在互斥资源的管理上。而混乱的互斥资源管理反而会导致更多严重问题的出现。

例如若要实现一个如下图所示的循环缓冲区，可以使用读写锁，仅使用原子变量表示读写index，并使用该原子index做到Berstein条件即可。

而原子操作对应的头文件为 <asm/atomic.h> ，常见的操作方法如下：

// 设置初始值
void atomic_set(atomic_t *v, int i);
// 可用于但不仅用于静态初始化
atomic_t v = ATOMIC_INIT(0);
// 读取
int atomic_read(atomic_t *v);
// 加减运算
void atomic_add(int i, atomic_t *v);
void atomic_sub(int i, atomic_t *v);
// 自增自减
void atomic_inc(atomic_t *v);
void atomic_dec(atomic_t *v);
// 带判定是否为0的减法及自增自减方法，返回值仅有0或1，与 atomic_*_and_return 方法不同
// (注意不存在加法函数，即不存在 `atomic_add_and_test` 方法)
int atomic_inc_and_test(atomic_t *v);
int atomic_dec_and_test(atomic_t *v);
int atomic_sub_and_test(int i, atomic_t *v);
// 执行加法并判定是否为负，返回值仅有0或1
int atomic_add_negative(int i, atomic_t *v);
// 执行自增自减或加减并返回结果，与 atomic_*_and_test 不同
int atomic_add_return(int i, atomic_t *v);
int atomic_sub_return(int i, atomic_t *v);
int atomic_inc_return(atomic_t *v);
int atomic_dec_return(atomic_t *v);
复制

此外，内核还提供了一组原子位操作，可以用于操作非原子变量。这些原子位操作速度非常快，在架构支持的情况下仅需要一个机器指令就可以完成，则这些平台进行此类操作的时候就可以不关闭中断。但是其实现也高度依赖于具体平台，用于表述目标位的 nr 参数通常为 int ，但是有时会被定义为 unsigned long ；要修改的元素通常用 unsigned long * 来做指针，但在一些平台中会被定义为 void* 。其主要的API如下：

void set_bit(nr, void* addr);
void clear_bit(nr, void* addr);
void change_bit(nr, void* addr);
test_bit(nr, void* addr);
int test_and_set_bit(nr, void* addr);
int test_and_clear_bit(nr, void* addr);
int test_and_change_bit(nr, void* addr);
复制

通常来说并不建议使用原子位操作，而建议改用自旋锁进行操作。

seqlock与信号量不同，其不需要任何阻塞操作。其通常用于处理读者写者问题，但是只能解决仅有一个写者的情况。
seqlock的使用与原理如下：

int seq = 0;

void reader()
{
	int value = 0;
	// 等待进入临界区，进入临界区条件为seq为偶数
	while(seq % 2);
	// 进入临界区
	do {
		if(seq_old != seq)
			seq_old = seq;
		value = Read();
	} while(seq_old != seq);
}

void writer()
{
	seq ++;
	write();
	seq ++;
}
复制

在上述原理中，写者：

1. 进入临界区之前将seq++，使此时seq为奇数。
2. 写入数据。
3. 再次seq++，使seq值为偶数并且与原先seq值不重复。
   读者：
4. 进入临界区之前判定顺序锁的值是否为偶数，不为偶数时等待写者离开(此时写者占有互斥资源)
5. 顺序锁为偶数，进入临界区，并在读取操作前备份seq值
6. 读取数据
7. 校验seq是否被更改，若被更改则证明在此期间写者已修改数据，原数据失效，需要重新读取。

注意：不要用seqlock保护一个指针，因为指针在writer里面很可能会被修改为NULL等一旦访问就会触发错误的值。

seqlock的头文件位于 <linux/seqlock.h> ，使用方法如下：
初始化：

// 静态初始化
seqlock_t lock = SEQLOCK_UNLOCKED;
// 动态初始化
seqlock_t lock;
seqlock_init(&lock);
复制

执行读取任务：

int reader()
{
	unsigned int seq = 0;
	do {
		// 下一句可能会进行自旋操作，直到写者退出
		seq = read_seqbegin(&lock);
		// Do sth...
		read();
	} while read_seqretry(&lock, seq);
}
复制

上述代码中的 read_seqbegin 、 read_seqretry 分别可以换成如下的任意版本：

unsigned int read_seqbegin_irqsave(seqlock_t *lock, unsigned long flags);
复制

int read_seqretry_irqrestore(seqlock_t *lock, unsigned long flags);
复制

执行写入任务直接使用如下API即可

void write_seqlock(seqlock_t *lock);
void write_sequnlock(seqlock_t *lock);

void write_seqlock_irqsave(seqlock_t *lock, unsigned long flags);
void write_seqlock_irq(seqlock_t *lock);
void write_seqlock_bh(seqlock_t *lock);

void write_sequnlock_irqrestore(seqlock_t *lock, unsigned long flags);
void write_sequnlock_irq(seqlock_t *lock);
void write_sequnlock_bh(seqlock_t *lock);
复制

RCU方法是一个高级的互斥机制，尽管它很少的被用于驱动程序设计中。不过在路由表和Starmode的射频IP驱动仍使用了该方法。
RCU是一个支持一个写者和多个读者同时进行操作的一个互斥机制(但不意味着至多只有一个写者)。RCU适用于需要频繁的读取数据，而修改数据并不多的情景。例如在文件系统中，经常需要查找定位目录，而对目录的修改相对来说并不多，这就是RCU发挥作用的最佳场景。

RCU的基本流程：
读者：

1. 获取RCU锁(关中断，保持原子操作)
2. 使用读者和写者所用指针读取数据
3. 释放RCU锁(开中断)

写者：

1. 为新数据分配新的内存地址
2. 将读者和写者所用指针指向新的地址

资源回收：

1. 等待所有CPU完成一次任务调度
2. 清除所有过时资源

注意，Linux的RCU并不依赖引用计数器，因为引用计数器本身的互斥保护也是一个麻烦的事情。在Linux中，RCU的基本规则是所有读者对该数据的访问均以原子操作进行，从而保证在进行读者的原子操作时不会被抢占。随后，当所有处理器都完成一次任务调度后(此时保证了所有读者完成对资源的读取)即可进行资源的清除工作。RCU的性能表现比自旋锁要好。

资源的清除工作通过预先设置的回调函数实现，通常该函数的工作内容就是调用 kfree 。

void call_rcu(struct rcu_head* head, void(*func)(void *arg), void *arg);
复制

如上文所述， ioctl 的接口定义如下：

int (*ioctl)(struct inode *inode, struct file *filep, unsigned int cmd, unsigned long arg);
复制

上述接口中的参数：

• struct inode * 和 struct file * 的定义与用法和Linux驱动开发笔记 > 5 8 open和release方法中的一致，内核负责将用户态的 ioctl 中指定的 fd 转化为这两个数据结构。
• cmd 则和用户态中传入的对应参数完全保持一致，而在用户态和内核态对该参数含义的约定也应当保持一致，通常用对应的头文件来实现。而内核态对 cmd 参数的处理通常可以使用 switch 方法。至于 cmd 参数的命令编号原则可见章节Linux驱动开发笔记 > 8 1 3 cmd命令编号原则。

而返回值也应当从 <linux/errno.h> 中选值返回，常用的值如下：

• -ENOTTY ：POSIX标准规定的指定的命令非法的返回值

注意：老的ioctl会在获得大内核锁(BKL)的条件下运行，所以应当尽快处理并返回。

此外，更大的问题在于老的ioctl方法是由内核的大内核锁(BKL)实现并发控制的，驱动在ioctl中较长的占用处理器则会导致无关的进程会被该ioctl产生较长时间的系统调用延迟()。为了解决此问题(The new way of ioctl())，Linux在2.6.11开始引入了 unlocked_ioctl 和 compat_ioctl ，并在Linux 2.6.36彻底删除了 ioctl 接口。

正如上文所述，在64位系统上运行32位的用户态程序会导致传输传递时字节大小不匹配的问题。因此无论在32位还是64位的系统上都需要分别实现这两个函数。其调用情况为：

几个注意点：

1. 在32位系统上调用ioctl，对应的实现也是 unlocked_ioctl 只是位宽不一样。
2. 在这两个接口中：
   • compat_ioctl 意味"兼容性的ioctl"
   • unlocked_ioctl 意味"解锁的ioctl"，此函数不会为内核施加大内核锁，且此时需要驱动程序管理自己的互斥锁。

在ioctl传参时，应当注意传递的是实际参数还是指针。传递普通参数时正常实现即可，当传递指针时应当注意该用户空间的指针是否合法，其方法主要分为如下几类：

1. 传输大批量的内存数据时，使用 copy_from_user 或 copy_to_user 即可。
2. 传输小批量数据时，可以使用如下函数进行校验：

int access_ok(int type, const void *addr, unsigned long size);
复制

其中， type 可以选择 VERIFY_READ 或 VERIFY_WRITE ，参数 addr 指用户空间地址，参数 size 指要传输的字节数。注意， VERIFY_WRITE 是 VERIFY_READ 的超集。 access_ok 将返回0或1。
随后即可使用 <asm/uaccess.h> 中的无需检查的宏函数进行传输(预处理时展开)：

• __put_user(x, ptr) ： x 为内核态数据、 ptr 为用户指针
• __get_user(x, ptr) ： x 为内核态数据、 ptr 为用户指针
  注意：
• access_ok 只负责检验该内存地址是否位于进程对应有权限访问的区域内
• 在使用 access_ok 后可以使用Linux为常用的1、2、4、8字节类型提供的，尽管大部分代码并不需要使用 access_ok 进行访问。

3. 直接使用含可访问检查(已内置无需再次 access_ok )的宏函数(预处理时展开)：
   • put_user(x, ptr) ： x 为内核态数据、 ptr 为用户指针
   • get_user(x, ptr) ： x 为内核态数据、 ptr 为用户指针

注意：2和3仅可用于sizeof为1、2、4、8字节大小的参数传递，其他类型无法使用。
宏函数内置的sizeof是对用户空间的指针所指对象大小进行计算(即 sizeof(*(ptr)) )

在驱动程序中，对设备的操作也应当分为不同的权限等级，例如读取硬盘、写入硬盘以及格式化硬盘本就不应当是同一组权限。而在Linux中也内置了一些权限，例如在 <linux/capability.h>
中预先定义了如下一些可能常用的权限：

• CAP_DAC_OVERRIDE ：
• CAP_NET_ADMIN ：执行网络管理任务的权限，例如配置网络接口
• CAP_SYS_MODULE ：载入或者卸载内核模块的权限
• CAP_SYS_RAWIO ：执行裸IO的权限，例如直接使用I2C或者USB通信
• CAP_SYS_ADMIN ：
• CAP_SYS_TTY_CONFIG ：执行tty配置任务的权限
  在内核驱动中，可以使用 <sys/sched.h> 中的如下API检查是否有对应权限：

int capable(int capability);
复制

对于不满足权限的请求可以返回 -EPREM 。

阻塞和休眠通常都是由等待一个事件或资源引起的，因此其等待的时间通常具有不可预测的特性。在进入休眠时，务必注意下列注意事项：

1. 不可在原子上下文中进行休眠。因为原子操作通常依靠自旋锁、顺序锁甚至是关闭中断来实现的。在这里进行休眠及其容易造成死锁或其他系统稳定性相关的问题。在进入休眠时需检查如下事项：
   1. 休眠时不可拥有(因为下述机制本就是为避免休眠切约定不可休眠的互斥方法)：
      • 自旋锁
      • 顺序锁
      • RCU锁
   2. 休眠时不可关闭中断
2. 休眠时允许拥有信号量，则务必关注可能会被该信号量影响的线程，且需要注意不要构成循环等待这种死锁情况。(该线程所持有的信号量所阻塞的线程拥有该线程所等待的资源)
3. 在进行休眠时，务必确保有其他线程或进程会唤醒本进程。

在Linux中的头文件 <linux/wait.h> 中提供了阻塞与休眠相关的API，其较为重要的使用方法如下：

1. 休眠和唤醒通常通过等待队列来实现，可以通过如下的方法静态或动态的定义一个等待队列：

// 静态定义
DECLARE_WAIT_QUEUE_HEAD(name);

// 动态定义
wait_queue_head_t q_head;
init_waitqueue_head(&q_head);
复制

2. 休眠指令，注意该休眠指令实际上为宏函数：

// 休眠API(注意都是宏函数)

/**
 * @brief: 休眠直到condition为true
 * @note: 每次wq_head被唤醒都会被执行并判定condition
 */
wait_event(wq_head, condition)

/**
 * @brief: 休眠直到condition为true，支持系统被挂起期间冻结
 */
wait_event_freezable(wq_head, condition)

/**
 * @brief: 休眠直到condition为true，或者超时(以jiffy表示)时中断休眠。
 * @return:
 *     - 当超时后condition为true返回0
 *     - 当超时后condition为false返回1
 *     - 超时前condition为true则返回剩余jiffy数(大于等于1)
 */
wait_event_timeout(wq_head, condition, timeout)

/**
 * @brief: 休眠直到condition为true。在执行等待前和后，cmd1和cmd2会分别被执行
 * @return:
 *     - 当其被信号打断时返回值为非零
 */
wait_event_cmd(wq_head, condition, cmd1, cmd2)

/**
 * @brief: 休眠直到condition为true，或者被信号中断休眠。当其被信号打断时返回值为非零。
 * @return:
 *     - 当其被信号打断时返回值为非零
 */
wait_event_interruptible(wq_head, condition)
复制

注：

• 上述 condition 是一个不带副作用的 bool 表达式，该表达式可能会被多次求值。

3. 唤醒指令。休眠和唤醒通常伴随出现。

// wake_up会唤醒所有等在queue上的线程
wake_up(x)

// wake_up_interruptible只会唤醒可中断休眠的线程
wake_up_interruptible(x)
复制