Linux驱动认知简明导论 ① —— 从用户空间贯穿到底层驱动

最新推荐文章于 2022-10-14 22:48:34 发布

汉密士20240101

最新推荐文章于 2022-10-14 22:48:34 发布

阅读量271

点赞数

分类专栏： # Linux驱动开发文章标签： Linux 驱动操作系统

本文链接：https://blog.csdn.net/weixin_46959681/article/details/116765305

版权

Linux驱动开发专栏收录该内容

3 篇文章 0 订阅

订阅专栏

原创首发于CSDN，转载请注明出处，谢谢！https://blog.csdn.net/weixin_46959681/article/details/116765305

文章目录

前言

笔者曾在博文——Linux 文件系统——“文件类型”小节里的设备文件 /dev 添加过注释：使用单片机点亮led灯与通过Linux内核驱动点亮led灯，两者天差地别，后者所需要的知识储备是前者的十倍不止。这一句话主要体现在以下两个方面：

嵌入式应用开发工程师与单片机工程师。 前者在技术层面上对后者而言是降维打击，如在内核中添加驱动程序、交叉编译工具链的部署、系统中进程的通信，这些都不是单片机的范围。另外，不论在就业薪水亦或在其他技术领域内，前者都比后者要宽广的多。；
Linux系统庞大的学习体系。 相比于单片机而言，Linux系统的学习路线更加陡峭，知识体系也更加庞大。在笔者所加的技术交流群中，经常可以看到一些新手小伙伴对于Linux系统的学习体系感到疑惑，比如为什么要学习文件描述符？进程、进程间通信、线程又是怎么一回事？网络编程又是什么？最要命的是，与单片机的寄存器操作比较，同样一件事为什么用Linux系统实现就如此复杂？之所以会有上述的困惑（知识学习、实际的硬件动作），本质上还是不具备整体的宏观视角 —— 程序在最上层的用户态空间被触发运行，它是怎样在多层级的Linux操作系统中传导信号，最终与底层的设备驱动文件交互实现控制实体硬件。

基于上文我们开可以这么提问：“为什么在Linux中对文件的操作能“识别”其文件的类型（内存、网卡、外设串口……）？” 这和第二个方面的讲述是一致的。

$备注：$

相当多的单片机工程师是从通信、仪器、仪表、自动化、电子专业、微电子、机械等专业跨行业上岗，不懂操作系统、计算机网络十分正常。同理，对于学习从事计算机纯软件出身的人员上手单片机也会有障碍。但嵌入式软件工程师来说，必须要懂操作系统。关键还是在于不断学习，系统性学习是提升专业性的重中之重。

从用户态空间贯穿到底层驱动

“一切皆文件” —— 在Linux系统中对于文件的所有操作离不开三个通用的API函数：open、read、wirte，例如使用函数open打开一个引脚4文件 pin4 到与底层硬件交互时，一共会经过以下三步：

在用户态空间调用函数 OPEN 触发进程 open("/dev/pin4",O_RDWR)，产生一个软中断（中断号 0x80）进入内核空间；
内核会调用函数 sys_call（System call interface），根据设备的文件名在内核的驱动链表中寻找设备的设备号（分为主设备号、次设备号，请阅读第一篇参考博文）；
在寻找到设备号之后调用函数sys_open，再调用对应的驱动文件里的open，最终实现寄存器的电平操作。「在最终的硬件动作方面，单片机与Linux本质上是一样的。」

$注意$ ⚠️：

磁盘里的引脚文件pin4与真正的引脚的驱动文件pin4Driver两者所在位置并不相同，也不属于同一类型文件。从sys_call到sys_open中间实际上经过一层虚拟文件系统VFS，做到了不同文件系统但有了统一的接口。

说明

延续笔者对于个人博客写作的理解，这一篇给大家一个自上到下的宏观视角，对于其他的细碎概念和实际操作，如 主次设备号、 基于驱动框架的驱动程序编写 、内核中驱动链表的管理（驱动文件的插入/加载、查找） 等，笔者都会给出参考博文或者在下一篇的实操博文里进行讲解。本人博客的重心多放在所遇技术问题的图式背景，相应的解决操作方法以及由此衍生出来的新问题。