题主这个问题其实暴露了:很多人并不理解“驱动程序”这个概念。
楼下答主的回答,也是不正确的。
首先上结论:CPU没有什么驱动程序一说。
1. 什么是驱动程序?
首先,驱动程序,仍然是一个程序,只不过它是用来“驱动”的。那么它究竟“驱动”的是什么呢?答案其实很简单,驱动程序其实驱动的就是外部设备——比如:键盘,鼠标,网卡,显卡,声卡,……
很多朋友看到这里,可能会问:貌似现在普通用户都没有和驱动程序打过交道,都是直接安装好操作系统就直接OK了,都没有单独安装过什么键盘驱动、鼠标驱动、网卡驱动、显卡驱动、声卡驱动啊?
这里其实暗含了一个问题:
2. 驱动程序与操作系统的关系是什么?
普通用户并不直接和驱动程序打交道,而是和操作系统打交道。你可以,把普通用户想象成住着大别墅的富豪一家人,把操作系统想象成一个事无巨细的大管家,富豪一家人享受着大管家提供的各项服务,而不需要亲自去操心这些服务是怎么实现的。
比方说,洗衣、熨烫等服务,有可能是专门的洗衣店来完成的,大管家只需要和洗衣店约定好一组接口:洗衣店的地址、联系方式、上门取/送衣服的流程等,那么大管家就可以确保这个服务可以让富豪一家子完美享受到了。在这个场景中,你可以把洗衣店想像成驱动程序,约定好的那组接口可以想象成操作系统与驱动程序交互的接口。
综上所述,操作系统就是用来向用户提供服务的平台,而驱动程序则是相关服务的实际提供者。两者之间通过约定好的接口规范来确保交互的正常运行。
3. 驱动程序与操作系统的交互接口规范是怎样的?
虽然从理论上说,操作系统与驱动程序之间的接口是两者协商的,但是因为通常操作系统的厂商的话语权更大,所以实际情况中,基本上是由操作系统来定义接口规范,驱动程序厂商来根据接口规范来进行开发、将对外部设备硬件的操作适配到这些接口规范中。
因为市面上主流的操作系统并不是一家公司开发的,所以不同的操作系统通常有不同的接口规范。
比方说,在Windows平台上,驱动程序的架构和接口规范通常要遵循WDF(Windows Vista/Windows 7之后)、WDM(Windows NT/2000/XP之后)、VxD(Windows 95/98等)。而在Linux平台上,驱动程序的架构和接口规范基本上都是衍生与VFS(虚拟文件系统)。
此外,即使在同一操作系统平台上,不同类型的驱动程序,对应的接口规范也会不一样。
比方说,在Windows平台上,网络驱动程序,遵循的是NDIS规范;而显示驱动,遵循的有DirectX和OpenGL接口规范……
可能会有朋友要问了:前面你不是说Windows的驱动程序都遵循WDF/WDM/VxD这些接口规范吗?怎么这里又来了个NDIS?
简单来说,WDF/WDM/VxD这些是通用架构,而NDIS这些是根据具体的设备类型,在这个通用架构上做了优化、将一些通用操作的代码直接帮你编写好了,节省开发者的精力和时间。
4. 为什么说CPU没有驱动程序的概念?
前面已经说了,驱动设备是针对外部设备的,而CPU不是外部设备,所以不存在驱动程序的概念。
那么CPU是怎么运行的呢?如笔者在专栏《华为方舟编译器源代码》的第一章《CPU的本质是什么?》中所揭示的:CPU本质就是一堆“开关”,它是利用物理规律来实现“开”、“合”状态,从而来与二进制的1和0对应的。换言之,CPU的这堆“开关”通过“开”、“合”状态,就模拟了一堆二进制指令。
5. CPU与驱动程序的关系是什么?
正如前面所介绍的,与驱动程序直接打交道的是操作系统,CPU并不直接和驱动程序相关。
通常来讲,操作系统厂商,需要研究对应的CPU架构,来充分发挥对应CPU的性能和特性。
比方说,当年微软为了充分发挥386芯片的虚拟内存和多任务管理等能力,研发了Windows NT操作系统。
再比方说,线程调度等多任务协同工作,是操作系统利用CPU的中断机制和相关的“门”机制实现的。基于这些原理,加上DMA(直接存储访问)控制器的加持,就可以实现DMA的大规模数据传输,在这个场景中:
操作系统只需要告诉CPU:“有一大坨数据要通过DMA传输了,它们的位置是XXX,请求放行”,然后CPU回答操作系统:“朕准了!总线放行,搞完了记得通知朕,朕好收回总线权利”,接着操作系统告诉DMA控制器:“兄弟,可以开搞了!”DMA控制器就开始噼里啪啦和外部设备一起配合“搬砖”了……