Linux内核主要包括三种驱动模型:字符设备驱动、块设备驱动以及网络设备驱动。其中,字符设备驱动是Linux驱动开发中最常见、最基础的驱动模型。
本文将从内核源码角度出发,拆解字符设备驱动的机制,涵盖:
字符设备号管理:内核如何分配和追踪设备号
字符设备对象(cdev):内核如何抽象和管理字符设备
kobj_map 哈希映射机制:设备号到 cdev 的快速查找
mknod 与 open 系统调用全链路:从用户态到内核驱动的完整路径
共享内存字符设备驱动案例:简单的字符设备驱动使用方法代码
📌 提示:本文基于 Linux 内核 5.x 版本源码进行分析,主要源码文件位于
fs/char_dev.c
include/linux/cdev.h
drivers/base/map.c
一、字符设备号管理
本小节的主线是内核如何管理哪些设备号已经分配,哪些设备号可用
1.1 dev_t 设备号概述
在Linux内核中,每个字符设备都由一个32 位的设备号(dev_t)唯一标识。这个 32 位数值被划分为两部分:
主设备号(Major Number):占用高 12 位(bit 12-31),用于标识设备驱动类型
次设备号(Minor Number):占用低 20 位(bit 0-19),用于区分同一驱动下的不同设备实例
内核提供了三个关键宏来操作设备号:
#defineMINORBITS20#defineMINORMASK ((1U << MINORBITS) - 1)#defineMAJOR(dev) ((unsignedint) ((dev) >> MINORBITS)) /* 提取主设备号 */#defineMINOR(dev) ((unsignedint) ((dev) & MINORMASK)) /* 提取次设备号 */#defineMKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) /* 组合生成设备号 */💡 设计思想:主设备号相当于"设备类型标识",例如所有I2C设备共享一个主设备号;次设备号则用于区分具体是哪个I2C设备(如 MPU6050 传感器还是 EEPROM 存储器)。这种分层设计使得内核可以在保持设备号空间紧凑的同时,支持大量设备实例
1.2 char_device_struct 结构体
内核通过char_device_struct结构体来记录系统中已分配的设备号范围(主设备号 + 次设备号区间),形成一个资源管理表,防止设备号冲突。内核维护了chrdevs哈希表来记录设备号的使用情况:
/* 定义在 fs/char_dev.c */#define CHRDEV_MAJOR_HASH_SIZE 255staticstructchar_device_struct{
structchar_device_struct*next;/* 将相同哈希值的节点链接成链表 */
unsignedintmajor; /* 主设备号 */
unsignedintbaseminor; /* 次设备号起始值 */
intminorct; /* 次设备号数量 */
charname[64]; /* 设备名称 */
structcdev*cdev; /* 内核字符对象(已废弃) */
} *chrdevs[CHRDEV_MAJOR_HASH_SIZE];
🔑 关键设计:内核使用chrdevs维护设备号的分配信息
chrdevs数组大小仅为 255,但主设备号范围是 0~511(甚至理论上可以更大)。内核通过取模操作major % 255将主设备号映射到哈希桶。具体来说:
主设备号 0、255、510... 都落在桶 0
主设备号 1、256、511... 都落在桶 1
桶内链表按主设备号从小到大排序
这种设计下:在不增加数组规模的前提下,理论上支持无限的主设备号范围,且查找效率不受影响。

1.3 __register_chrdev_region 函数
__register_chrdev_region是设备号分配的核心函数,负责在chrdevs哈希表中查找或插入一个空闲的设备号区间,并返回对应的char_device_struct指针
/* 定义在 fs/char_dev.c */staticstructchar_device_struct*__register_chrdev_region(unsignedintmajor,unsignedintbaseminor,intminorct,constchar*name) {
structchar_device_struct*cd, **cp;
intret=0; inti;/* 1. 分配新的 char_device_struct 节点 */
cd=kzalloc(sizeof(structchar_device_struct),GFP_KERNEL);
if(cd==NULL)
returnERR_PTR(-ENOMEM);
mutex_lock(&chrdevs_lock);
/* 2. 如果 major == 0,动态分配主设备号 */
if(major==0) {
ret=find_dynamic_major();
if(ret<0) {
pr_err("CHRDEV \"%s\" dynamic allocation region is full\n",name);
gotoout;
}
major=ret;
}
/* 3. 主设备号范围校验 */
if(major>=CHRDEV_MAJOR_MAX) {
pr_err("CHRDEV \"%s\" major requested (%u) greater than max (%u)\n",name,major,CHRDEV_MAJOR_MAX-1);
ret= -EINVAL;
gotoout;
}
cd->major=major;
cd->baseminor=baseminor;
cd->minorct=minorct;
strlcpy(cd->name,name,sizeof(cd->name));
/* 4. 计算哈希桶位置 */
i=major_to_index(major);
/* 5. 在链表中找到合适的插入位置(按主设备号、次设备号排序) */
for(cp= &chrdevs[i]; *cp;cp= &(*cp)->next) {
if((*cp)->major>major||
((*cp)->major==major&&
((*cp)->baseminor>=baseminor||
(*cp)->baseminor+ (*cp)->minorct>baseminor)))
break;
}
/* 6. 检查次设备号是否冲突(三种重叠检测) */
if(*cp&& (*cp)->major==major) {
intold_min= (*cp)->baseminor;
intold_max= (*cp)->baseminor+ (*cp)->minorct-1; intnew_min=baseminor; intnew_max=baseminor+minorct-1;/* 新范围与已有范围重叠 → 冲突 */
if(new_max>=old_min&&new_max<=old_max) {
ret= -EBUSY;
gotoout;
}
if(new_min<=old_max&&new_min>=old_min) {
ret= -EBUSY;
gotoout;
}
/* 新范围完全覆盖已有范围 */
if(new_min<old_min&&new_max>old_max) {
ret= -EBUSY;
gotoout;
}
}
/* 7. 插入链表 */
cd->next= *cp;
*cp=cd;
mutex_unlock(&chrdevs_lock);
return cd;out:
mutex_unlock(&chrdevs_lock);
kfree(cd);
returnERR_PTR(ret);
}
🔑 冲突检测逻辑解析:内核在插入新设备号时,会检查三种可能的冲突场景:
新范围尾部与已有范围重叠:
new_max落在[old_min, old_max]区间内新范围头部与已有范围重叠:
new_min落在[old_min, old_max]区间内新范围完全覆盖已有范围:
new_min < old_min且new_max > old_max
只有三种情况都不满足时,才认为设备号范围无冲突,可以安全注册。
1.4 find_dynamic_major 函数
当驱动调用alloc_chrdev_region(传入 major=0)请求动态分配设备号时,内核会调用find_dynamic_major从空闲范围中查找可用的主设备号:
staticintfind_dynamic_major(void){
inti;
structchar_device_struct*cd;/* 高优先级:在 234~254 范围内查找 */
for(i=ARRAY_SIZE(chrdevs) -1;i>=CHRDEV_MAJOR_DYN_END;i--) {
if(chrdevs[i] ==NULL)
returni;
}
/* 低优先级:在 511~384 范围内查找 */
for(i=CHRDEV_MAJOR_DYN_EXT_START;i>=CHRDEV_MAJOR_DYN_EXT_END;i--) {
for(cd=chrdevs[major_to_index(i)];cd;cd=cd->next) {
if(cd->major==i)
break;
}
if(cd==NULL)
returni;
}
return-EBUSY;
}
📌 两级查找策略:
| 优先级 | 查找范围 | 说明 |
|---|---|---|
相关宏定义:
CHRDEV_MAJOR_MAX 512CHRDEV_MAJOR_DYN_END 234CHRDEV_MAJOR_DYN_EXT_START 511CHRDEV_MAJOR_DYN_EXT_END 384
1.5 设备号分配的两大对外接口
内核提供了两种设备号分配方式,对应不同的使用场景:
| 接口 | 方式 |
|---|---|
register_chrdev_region() | 静态分配 |
alloc_chrdev_region() | 动态分配 |
两者最终都调用__register_chrdev_region()完成实际注册操作。在Linux系统中,可以通过cat /proc/devices查看所有已注册的设备号列表。设备号注销时,无论静态还是动态分配,统一调用unregister_chrdev_region()归还资源
二、字符设备对象(cdev)
本小节的主线是了解两个结构体的设计,分别是内核字符设备结构体cdev,以及管理字符设备的结构体kobj_map。
2.1 cdev 结构体
struct cdev是内核中表示字符设备的核心数据结构。每个字符设备驱动都需要创建一个cdev实例,并将其注册到内核中:
/* 摘自 include/linux/cdev.h */structcdev{
structkobjectkobj; /* 内嵌的kobject,用于设备模型管理 */
structmodule*owner; /* 指向所属模块,通常为THIS_MODULE */
conststructfile_operations*ops; /* 设备操作函数集 */
structlist_headlist; /* 用于将cdev链接到对应设备号的cdev列表 */
dev_tdev; /* 记录该字符设备关联的起始设备号 */
unsignedintcount; /* 从dev开始连续占用的次设备号数量 */
}__randomize_layout;
| 成员变量 | 作用 |
|---|---|
kobj | |
owner | |
ops | |
list | |
dev | |
count |
2.2 kobj_map 结构体(哈希表)
struct kobj_map是一个内核内部结构体,定义在drivers/base/map.c中,用于建立设备号(dev_t)到 struct cdev 的快速查找映射。
kobj_map负责将设备号范围映射到对应的struct cdev结构体。当内核通过设备号访问字符设备时(如打开设备文件时),会根据设备号在kobj_map中查找对应的struct cdev,从而获得其操作函数集void *data指针中保存了cdev结构体指针probes数组是一个哈希桶,每个桶是一个链表,链表节点记录了设备号范围及对应的data(通常指向struct cdev)和获取kobject的函数通过
cdev_add将一个cdev添加到系统中时,实际上就是在kobj_map中插入一个节点
/* 摘自 drivers/base/map.c */structkobj_map{
structprobe{
structprobe*next; /* 链表下一个节点 */
dev_tdev; /* 起始设备号 */
unsignedlongrange; /* 次设备号范围 */
structmodule*owner; /* 模块所有者 */
kobj_probe_t*get; /* 获取kobject的函数(用于查找) */
int(*lock)(dev_t,void*); /* 锁定函数 */
void*data; /* 私有数据,通常指向cdev */
} *probes[255]; /* 255个桶的哈希表 */
structmutex*lock; /* 保护映射表的锁 */
};
🔑 chrdevs 和 cdev_map —— 两套哈希表的职责分工:
| 哈希表 | 存储内容 | 职责 |
|---|---|---|
chrdevs | ||
cdev_map |
三、cdev 注册函数
本小节的主线是内核如何将用户定义的cdev结构体注册到内核cdev_map中
3.1 cdev_init 函数
cdev_init用于初始化一个已经分配的cdev结构体,将其与文件操作集关联,并设置内嵌kobject的类型:
voidcdev_init(structcdev*cdev,conststructfile_operations*fops) {
memset(cdev,0,sizeof*cdev); /* 清零结构体 */
INIT_LIST_HEAD(&cdev->list); /* 初始化链表头 */
kobject_init(&cdev->kobj, &ktype_cdev_default); /* 初始化内嵌kobject */
cdev->ops=fops; /* 绑定文件操作集 */
}EXPORT_SYMBOL(cdev_init);
EXPORT_SYMBOL宏将该函数导出到内核符号表,使内核模块(.ko 文件)可以调用它。
3.2 cdev_add 函数
完成设备号,次设备数量等参数记录,并将字符设备注册到内核
intcdev_add(structcdev*p,dev_tdev,unsignedcount) {
interror;
p->dev=dev; /* 记录起始设备号 */
p->count=count; /* 记录次设备号数量 */
/* 调用kobj_map注册,将设备号范围映射到该cdev */
error=kobj_map(cdev_map,dev,count,NULL,exact_match,exact_lock,p);
if(error)
returnerror;
/* 增加模块引用计数,防止模块被卸载 */
kobject_get(p->kobj.parent);
return0;
}
EXPORT_SYMBOL(cdev_add);
3.3 kobj_map 函数
这是将 cdev 插入到全局哈希表cdev_map的核心函数,接下来才可以通过设备号查找对应的字符设备,定义在drivers/base/map.c中:
intkobj_map(structkobj_map*domain,dev_tdev,unsignedlongrange,
structmodule*module,kobj_probe_t*probe,
int(*lock)(dev_t,void*),void*data) {
/* 1. 计算跨越了几个不同的主设备号 */
unsignedn=MAJOR(dev+range-1) -MAJOR(dev) +1;
unsigned index = MAJOR(dev); unsigned i; struct probe *p; if (n > 255) n = 255; /* 安全限制 *//* 2. 分配 n 个连续的 probe 结构体 */
p=kmalloc_array(n,sizeof(structprobe),GFP_KERNEL);
if (p == NULL) return-ENOMEM;/* 3. 初始化 n 个 probe(每个的 data 都指向同一个 cdev) */
for(i=0;i<n;i++,p++) {
p->owner=module;
p->get=probe;
p->lock=lock;
p->dev=dev;
p->range=range;
p->data=data;
}
/* 4. 将 probe 节点插入哈希表,按 range 排序 */
mutex_lock(domain->lock);
for(i=0,p-=n;i<n;i++,p++,index++) {
structprobe**s= &domain->probes[index%255];
/* 按 range 大小排序,range 小的在前 */
while(*s&& (*s)->range<range)
s= &(*s)->next;
p->next= *s;
*s=p;
}
mutex_unlock(domain->lock);
return0;
}
💡 为什么按 range 排序?当查找设备号对应的 cdev 时,kobj_lookup函数会遍历链表,选择range最小且包含该设备号的 probe。这种"最佳匹配"策略确保当多个 cdev 的设备号范围有重叠时,能精确匹配到最具体的那一个。
四、字符设备号与字符设备对象的关系

chrdevs—— 设备号资源管理记录主设备号的使用区间,防止冲突。在驱动加载时调用register_chrdev_region或alloc_chrdev_region分配设备号时,进行冲突检测。cdev_map—— 运行时查找设备根据打开设备文件的设备号,快速找到cdev结构体,获得file_operations。在cdev_add函数中调用kobj_map函数构建哈希表。
五、次设备号的解析与多实例管理
本小节用一个非常简单的例子解析为什么需要区分主次设备号,一个主设备号是如何与多个次设备号关联起来的
在实际应用中,多个功能相同的子设备可以共用同一套驱动程序:
不同子设备功能逻辑一样,操作函数集(
open、read、write等)完全相同没必要为每个次设备号都分配一个 cdev,只需要一个cdev就能管理多个实例
用户空间看到三个独立的设备文件(
/dev/device1对应次设备号0,device2对应1,device3对应2),但内核中都导向同一个file_operations
5.1 注册 cdev
dev_tdevno=MKDEV(major,0); /* 起始次设备号 0 */cdev_init(&my_cdev, &fops);
cdev_add(&my_cdev,devno,3); /* 占用次设备号 0, 1, 2 */
5.2 定义设备私有结构体和数组
structmy_device{
void__iomem*regs; /* 该设备的寄存器映射地址 */
structmutexlock; /* 互斥锁 */
/* ... 其他私有数据 */};staticstructmy_devicedevs[3]; /* 三个实例 */
5.3 在 open 中用次设备号绑定私有数据
staticintmy_open(structinode*inode,structfile*filp) {
intminor=iminor(inode); /* 获取次设备号 */
if(minor<0||minor>=3)
return-ENODEV;
structmy_device*dev= &devs[minor]; /* 根据次设备号选择设备 */
filp->private_data=dev; /* 保存到私有数据中 */
return0;
}
📌 次设备号使用:这种"一个 cdev → 多个次设备号 → 多个设备实例"的模式是 Linux 驱动开发中的标准做法。通过iminor(inode)获取次设备号,再通过filp->private_data保存设备私有数据,后续的 read/write/ioctl 操作都能通过filp->private_data获取到正确的设备实例
六、mknod与 open系统调用的完整流程
本小节介绍从用户态打开一个字符设备驱动的完整流程,关注内核如何通过字符设备号找到对应的字符设备结构体,以及用户定义的操作函数如何被替换

6.1 系统调用的整体流程
让我们从用户态的一条命令开始
mknod/dev/mydevicec2500
这个命令触发的过程被拆解为四个关键步骤:
使用
mknod创建一个字符设备 inode 节点,该节点中保存了默认 open 函数chrdev_open。节点定义在/dev/mydevice在用户空间使用
open函数,传入"/dev/mydevice"通过一系列系统调用,最后到达
do_dentry_open函数,该函数会调用inode节点对应的默认 open 函数chrdev_openchrdev_open函数在全局哈希表cdev_map中,根据设备号找到用户定义的f_ops操作函数,并替换inode和file中的操作函数。至此,用户自定义的操作函数正式被调用
6.2 mknod创建 node节点
在控制台调用mknod函数时,经过一系列系统调用,最后会调用init_special_inode函数。该函数是 VFS 层处理特殊文件的基石,根据文件类型为inode挂载合适的操作函数表,并保存必要的设备号信息。
voidinit_special_inode(structinode*inode,umode_tmode,dev_trdev) {
inode->i_mode=mode; /* 保存文件类型和权限 */
if(S_ISCHR(mode)) {
/* 字符设备文件 */
inode->i_fop= &def_chr_fops; /* 默认字符设备操作表 */
inode->i_rdev=rdev; /* 保存设备号 */
}elseif(S_ISBLK(mode)) {
/* 块设备文件 */
inode->i_fop= &def_blk_fops;
inode->i_rdev=rdev;
}elseif(S_ISFIFO(mode))
/* 命名管道 */
inode->i_fop= &pipefifo_fops;
elseif(S_ISSOCK(mode)) ;
/* 套接字不设置操作表 */
else
printk(KERN_DEBUG"bogus i_mode for inode %s:%lu\n",inode->i_sb->s_id,inode->i_ino);
}
🔑 理解:此时 inode 中的i_fop指向的是def_chr_fops,一个仅包含默认 open 方法的操作表。真正的驱动专用操作函数表要等到用户调用open()时,才会通过chrdev_open函数动态替换。这是一种"延迟绑定"的设计模式
6.3 def_chr_fops —— 字符设备的默认操作函数
/* 来源: fs/char_dev.c */conststructfile_operationsdef_chr_fops= {
.open=chrdev_open, /* 只定义了一个 open 方法 */
.llseek=noop_llseek, /* 一个什么都不做的寻址函数 */
};
6.4 chrdev_open —— 字符设备 open 默认函数
chrdev_open是整个字符设备驱动机制中最关键的桥接函数:
/* 来源: fs/char_dev.c */staticintchrdev_open(structinode*inode,structfile*filp) {
structcdev*p;
struct cdev *new = NULL; int ret=0;/* 第一步:获取或查找 cdev */
p=inode->i_cdev;
if(!p) {
structkobject*kobj;
intidx;
/* 根据设备号在全局哈希表 cdev_map 中查找对应的 cdev */
kobj=kobj_lookup(cdev_map,inode->i_rdev, &idx);
if(!kobj)
return-ENXIO;
/* 通过 kobject 反推出包含它的 cdev */
new=container_of(kobj,structcdev,kobj);
/* 并发安全:再次检查并设置 inode->i_cdev(缓存优化) */
p=inode->i_cdev;
if(!p) {
inode->i_cdev=p=new;
inode->i_cindex=idx;
list_add(&inode->i_devices, &p->list);
new=NULL;
}
}
/* 第二步 ★核心★ 替换文件操作表 *//* 将 file 的 f_op 从 def_chr_fops 替换为驱动自己的 fops */
filp->f_op=fops_get(p->ops);
if(!filp->f_op)
return-ENXIO;
/* 第三步:调用驱动自身的 open 函数 */
if(filp->f_op->open) {
ret=filp->f_op->open(inode,filp);
}
returnret;
}
🔑 chrdev_open 三步走核心逻辑:
查找 cdev:通过
kobj_lookup()在全局哈希表中查找,用container_of反推出 cdev。首次查找后缓存到inode->i_cdev替换 f_op:
filp->f_op = fops_get(p->ops)——最关键的一步,将 file 的文件操作表从def_chr_fops替换为驱动自己的file_operations调用驱动 open:如果驱动实现了自己的 open 方法,则调用它。至此,后续对该文件的 read/write 等操作都会直接调用驱动的对应函数。
6.5 open 函数的完整调用链
6.5.1 用户态 open() 到系统调用入口
用户态的open()是 glibc 等 C 库提供的封装函数,它最终会触发系统调用__NR_open。在 x86-64 架构上,通过syscall指令陷入内核。
6.5.2 内核通用打开流程:do_sys_open → do_filp_open
do_sys_open将用户态的文件路径名拷贝到内核空间,构造open_how结构(包含打开标志和模式),然后调用do_sys_openat2:
SYSCALL_DEFINE3(open,constchar__user*,filename,
int,flags,umode_t,mode) {
returndo_sys_open(AT_FDCWD,filename,flags,mode);
}
longdo_sys_open(intdfd,constchar__user*filename,
intflags,umode_tmode) {
structopen_howhow=build_open_how(flags,mode);
returndo_sys_openat2(dfd,filename, &how);
}
do_sys_openat2执行三个关键动作:
staticlongdo_sys_openat2(intdfd,constchar__user*filename,
structopen_how*how) {
structfilename*tmp=getname(filename); /* 拷贝路径到内核空间 */
intfd=get_unused_fd_flags(how->flags); /* 分配空闲fd */
structfile*f=do_filp_open(dfd,tmp,how); /* ★路径查找并打开★ */
d_install(fd,f); /* 关联 fd 与 file */
returnfd;
}
6.5.3 路径查找与打开:path_openat → vfs_open
do_filp_open最终调path_openat(定义在 fs/namei.c),它完成路径的遍历(逐级查找目录项),找到 inode 节点,最后调用vfs_open来实际打开文件。
6.5.4 do_dentry_open —— 核心函数
do_dentry_open负责初始化struct file,并根据 inode 类型设置文件操作表,最终调用open方法。对于字符设备文件,inode->i_fop指向的是def_chr_fops。所以f->f_op->open实际上就是chrdev_open:
staticintdo_dentry_open(structfile*f,structinode*inode,
int(*open)(structinode*,structfile*)) {
f->f_mode=OPEN_FMODE(f->f_flags) |FMODE_LSEEK|FMODE_PREAD|FMODE_PWRITE;
f->f_inode=inode;
f->f_mapping=inode->i_mapping;
/* ★获取文件操作表:优先使用 inode->i_fop★ */
f->f_op=fops_get(inode->i_fop);
if(!f->f_op)
return-ENXIO;
if(open)
error=open(inode,f);
/* 否则调用文件操作表中的 open 方法 *//* 对于字符设备 = chrdev_open! */
if(!error&& (f->f_mode&FMODE_OPENED) &&f->f_op->open)
error=f->f_op->open(inode,f);
returnerror;
}
📌 完整调用链路总结:
用户态 open()→sys_open()→
do_sys_open()→do_sys_openat2()→
do_filp_open()→path_openat()→
vfs_open()→do_dentry_open()→
chrdev_open()(替换 fops)→驱动的 open()
七、字符设备驱动开发中的函数详解
7.1 container_of 宏
container_of是 Linux 内核中常用的宏之一,它通过一个结构体成员的指针,反向获取包含该成员的结构体的起始地址:
/*** container_of - 通过结构体成员指针获取父结构体指针* @ptr: 成员变量的指针* @type: 包含该成员的结构体类型* @member: 成员变量在结构体中的名称*/#definecontainer_of(ptr, type, member) ({ \ void *__mptr = (void *)(ptr); \ BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ !__same_type(*(ptr), void), \ "pointer type mismatch in container_of"); \ ((type *)(__mptr - offsetof(type, member))); })/* 简化理解版本: */#definecontainer_of(ptr, type, member) \ ((type *)((char *)(ptr) - offsetof(type, member)))该函数根据结构体成员变量的指针,通过该变量相对于结构体的偏移,得到了该变量对应的结构体的指针。这是一个非常灵活的用法,通过保存某个结构体变量的指针,可以通过该指针反向推出该结构体的指针。
💡 container_of 的应用场景:在 Linux 内核中,这个宏无处不在。比如在chrdev_open中,内核通过kobj_lookup拿到了 cdev 内嵌的kobject的指针,然后通过container_of(kobj, struct cdev, kobj)反推出完整的cdev结构体指针。这种"内嵌 + 反推"的设计是内核面向对象编程思想的经典体现
7.2 register_chrdev_region
register_chrdev_region是 Linux 内核中用于注册字符设备编号范围的函数。该函数为驱动程序预留一段连续的设备号(主设备号 + 起始次设备号),后续将字符设备(通过cdev_add)绑定到这些设备号上:
/*** register_chrdev_region - 注册字符设备编号范围* @first: dev_t 类型,指定要注册的起始设备号(使用 MKDEV(major, minor) 宏生成)* @count: 需要注册的连续设备号数量(次设备号的范围)* @name: 设备名称,会出现在 /proc/devices 文件中* 返回值: 成功返回 0* 参数无效返回 -EINVAL* 设备号被占用返回 -EBUSY*/intregister_chrdev_region(dev_t first, unsignedint count, constchar *name);7.3 THIS_MODULE
THIS_MODULE是一个宏,定义在<linux/module.h>头文件中。它本质上是一个指向当前模块的struct module结构体的指针:
当代码被编译为可加载内核模块(.ko)时,
THIS_MODULE指向该模块的struct module实例当代码被静态编译进内核(built-in)时,
THIS_MODULE通常被定义为NULL或一个无实际作用的占位符
staticstructfile_operationsmy_fops= {
.owner=THIS_MODULE, /* 防止模块在使用中被卸载 */
.open=my_open, .read=my_read,
.write=my_write,
.release=my_release,
};
structcdevmy_cdev;
cdev_init(&my_cdev, &my_fops);
my_cdev.owner=THIS_MODULE;
cdev_add(&my_cdev,devno,count);
内核通过owner字段知道哪个模块拥有这个字符设备。当用户空间程序通过系统调用(如open)打开设备文件时,内核会自动调用try_module_get(THIS_MODULE)增加模块的引用计数;当设备被关闭时,内核会调用module_put(THIS_MODULE)减少引用计数。
🔑 这样做的目的是确保模块在设备被打开期间不会被卸载。如果用户正在使用设备,而管理员执行rmmod试图卸载驱动,内核会检查模块的引用计数是否为零。若不为零(表示设备正在被使用),则卸载操作会被拒绝,防止因模块代码突然消失而导致系统崩溃。这是一个经典的"资源使用计数"保护模式。
7.4 file_operations 结构体
file_operations是把系统调用和驱动程序关联起来的关键数据结构:
| 函数指针 | 对应系统调用 | 说明 |
|---|---|---|
owner | ||
llseek | ||
read | ||
write | ||
open | ||
release | ||
unlocked_ioctl | ||
mmap | ||
poll |
八、案例:使用字符设备驱动实现共享内存
下面是一个完整的内核模块示例,演示如何使用字符设备驱动实现共享内存。这个驱动程序创建两个字符设备(次设备号分别为 0 和 1),每个设备拥有独立的 1024 字节共享内存区域,用户空间可以通过read/write/ioctl/lseek操作这些内存。代码参考了书籍Linux设备驱动详解
#include <linux/init.h>#include <linux/errno.h>#include <linux/mm.h>#include <linux/sched.h>#include <linux/module.h>#include <linux/ioctl.h>#include <linux/io.h>#include <linux/fs.h>#include <linux/cdev.h>#include <linux/uaccess.h>#include <linux/slab.h>#define GLOBALMEM_SIZE 1024#define GLOBALMEM_MAGIC 'M'#define MEM_CLEAR _IO(GLOBALMEM_MAGIC, 0)
/* ===== 设备私有数据结构体 ===== */structglobalmem_dev{
structcdevm_cdev; /* 内嵌的字符设备 */
unsignedcharmem[GLOBALMEM_SIZE]; /* 共享内存区域(1KB) */
};staticint globalmem_major = 266;struct globalmem_dev *globalmem_devp;/* 两个设备实例 *//* ===== open:用户打开设备文件时调用 ===== */staticintglobalmem_open(structinode*inode,structfile*filp) {
structglobalmem_dev*dev;
/* 通过 inode->i_cdev (指向内嵌的 m_cdev) 反推出 globalmem_dev */
dev=container_of(inode->i_cdev,structglobalmem_dev,m_cdev);
/* 保存到 file->private_data,供后续 read/write 使用 */
filp->private_data=dev;
return0;
}
/* ===== release:用户关闭设备文件时调用 ===== */
staticintglobalmem_release(structinode*inode,structfile*filp) {
return0;
}
/* ===== read:用户读取设备数据 ===== */staticssize_tglobalmem_read(structfile*filp,char__user*buf,size_tcount,loff_t*ppos) {
unsignedlongp= *ppos;
structglobalmem_dev*dev=filp->private_data;if(p>=GLOBALMEM_SIZE)
return0;
if(count>GLOBALMEM_SIZE-p)
count=GLOBALMEM_SIZE-p;
/* 从内核空间拷贝数据到用户空间 */
copy_to_user(buf, (void*)(dev->mem+p),count); *ppos=p+count;
returncount;
}
/* ===== write:用户写入设备数据 ===== */staticssize_tglobalmem_write(structfile*filp,constchar__user*buf,size_tcount,loff_t*ppos) {
unsignedlongp= *ppos;
structglobalmem_dev*dev=filp->private_data;if(p>=GLOBALMEM_SIZE)
return0;
if(count>GLOBALMEM_SIZE-p)
count=GLOBALMEM_SIZE-p;
/* 从用户空间拷贝数据到内核空间 */
copy_from_user(dev->mem+p,buf,count); *ppos=p+count;
returncount;
}
/* ===== llseek:用户调整文件读写位置 ===== */staticloff_tglobalmem_llseek(structfile*filp,loff_toffset,intorig) {
loff_tret;
switch(orig) {
case0:
/* SEEK_SET:从起始位置移动 */
if(offset<0|| (unsignedint)offset>GLOBALMEM_SIZE) {
ret= -EINVAL;
break;
}
filp->f_pos= (unsignedint)offset;
ret=filp->f_pos;
break;
case1:/* SEEK_CUR:从当前位置移动 */
if((filp->f_pos+offset) >GLOBALMEM_SIZE|| (filp->f_pos+offset) <0) {
ret= -EINVAL;
break;
}
filp->f_pos+=offset;
ret=filp->f_pos;
break;default:
ret= -EINVAL;
}
returnret;
}
/* ===== unlocked_ioctl:用户发送设备控制命令 ===== */staticlongglobalmem_ioctl(structfile*filp,unsignedintcmd,unsignedlongarg) {
structglobalmem_dev*dev=filp->private_data;
switch(cmd) {
caseMEM_CLEAR:
memset(dev->mem,0,GLOBALMEM_SIZE); /* 清空共享内存 */
break;
default:
return-EINVAL;
}
return0;
}
/* ===== 文件操作函数集 ===== */staticconststructfile_operationsglobalmem_fops= {
.owner=THIS_MODULE,
.open=globalmem_open,
.release=globalmem_release,
.llseek=globalmem_llseek,
.read=globalmem_read,
.write=globalmem_write,
.unlocked_ioctl=globalmem_ioctl,
};
/* ===== 模块加载函数 ===== */staticint__initglobalmem_init(void) {/* 1. 注册设备号:主 266,次 0~1,共 2 个 */
register_chrdev_region(MKDEV(globalmem_major,0),2,"globalmem");
/* 2. 为两个设备分配内存 */
globalmem_devp=kmalloc(2*sizeof(structglobalmem_dev),GFP_KERNEL);
memset(globalmem_devp,0,2*sizeof(structglobalmem_dev));
/* 3. 初始化并注册次设备号 0 */
cdev_init(&(globalmem_devp[0].m_cdev), &globalmem_fops);
globalmem_devp[0].m_cdev.owner=THIS_MODULE;
cdev_add(&(globalmem_devp[0].m_cdev),MKDEV(globalmem_major,0),1);
/* 4. 初始化并注册次设备号 1 */
dev_init(&(globalmem_devp[1].m_cdev), &globalmem_fops);
globalmem_devp[1].m_cdev.owner=THIS_MODULE;
cdev_add(&(globalmem_devp[1].m_cdev),MKDEV(globalmem_major,1),1);
return0;
}
/* ===== 模块卸载函数 ===== */staticvoid__exitglobalmem_exit(void) {
cdev_del(&(globalmem_devp[0].m_cdev));
cdev_del(&(globalmem_devp[1].m_cdev));
kfree(globalmem_devp);
dev_tdevno=MKDEV(globalmem_major,0);
unregister_chrdev_region(devno,2);
}
MODULE_AUTHOR("punch");MODULE_LICENSE("GPL");MODULE_DESCRIPTION("A simple shared memory character device driver");module_param(globalmem_major,int,S_IRUGO);module_init(globalmem_init);module_exit(globalmem_exit);
📌 驱动代码关键设计解析:
container_of 的使用:
在
globalmem_open中,通过inode->i_cdev反向推出globalmem_dev结构体private_data 传递:在 open 中将设备结构体保存到
filp->private_data,这是 Linux 驱动中传递上下文的标准模式copy_to_user / copy_from_user:内核和用户空间数据交换必须通过这些安全函数进行
IOCTL 命令定义:
_IO(GLOBALMEM_MAGIC, 0)用于防止命令冲突多实例管理:两个次设备号各自对应独立的
globalmem_dev实例,各拥有独立的 1024 字节共享内存
8.1 测试驱动
编译加载驱动后,进行以下步骤来使用:
# 1. 加载驱动模块
sudo insmod globalmem.ko# 2. 查看驱动是否加载成功(应看到主设备号 266 和 "globalmem")cat /proc/devices | grep globalmem# 3. 创建设备节点sudo mknod /dev/globalmem0 c 266 0sudo mknod /dev/globalmem1 c 266 1# 4. 设置权限sudo chmod 666 /dev/globalmem0 /dev/globalmem1# 5. 测试读写echo "Hello Linux Driver!" > /dev/globalmem0cat /dev/globalmem0# 6. 卸载驱动sudo rmmod globalmem💡 小结:本小节只是为了演示字符设备驱动的简单案例。实际开发中,建议使用alloc_chrdev_region动态分配设备号,避免冲突。同时使用class_create和device_create可以让内核自动在/dev下创建设备节点,省去手动mknod的步骤。这些都是Linux 2.6 之后推荐的新字符设备驱动编写方式
🎯 总结
本文从内核源码角度,完整梳理了 Linux 字符设备驱动的核心机制:
设备号管理(chrdevs):通过 255 大小的哈希数组,利用取模操作管理 0~511 乃至更大的主设备号空间,配合链表按顺序组织,提供了高效的设备号冲突检测机制。
cdev 对象与 kobj_map:cdev 是字符设备的抽象表示,cdev_map 是设备号到 cdev 的映射哈希表。两套哈希表各司其职——chrdevs 管理资源分配,cdev_map 支持运行时查找。
延迟绑定机制:inode 创建时只挂载默认的
def_chr_fops(仅含 chrdev_open),真正驱动专用的 fops 要等到用户 open 时才通过 chrdev_open 动态替换。完整调用链路:
open → sys_open → do_sys_open → do_filp_open → path_openat → do_dentry_open → chrdev_open(替换fops) → 驱动open()container_of 设计模式:通过内嵌结构体成员指针反推外围结构体,是 Linux 内核"面向对象"编程思想的集中体现。
引用计数保护:通过
THIS_MODULE和owner字段,防止设备在使用中被意外卸载。
文章内容为作者过往学习的笔记,接下来会按期更新,预计下一期更新内核结构体kobject解析。如果本文对你有帮助,欢迎点赞、在看、转发,让更多 Linux 驱动开发者受益 🚀
夜雨聆风