操作系统怎么知道有哪些硬件的

操作系统中的设备抽象

所有的操作系统目前都有两个抽象，设备抽象和驱动抽象，二者通过某种机制互相匹配，设备提供可操作资源的信息，驱动使用这些资源执行运算逻辑从而达到效果，驱动的信息在安装时提供，设备的信息可以由很多种方式提供。设备可以提供它能够使用的驱动有哪些，驱动也可以给出它能够给哪些设备使用，因此制造商既可以为某一个设备写驱动，也可以为某个驱动造设备

设备的资源大致上有，设备的可存储寄存器的地址范围，占用中断号等。驱动程序的本质就是读写这些寄存器，当然驱动程序在编写的时候并不知道为哪一个具体的设备服务，在其被调用的时候传递来设备的信息，其就可以知道设备的地址范围，此时的地址范围不能直接使用，因为驱动程序处于某个逻辑地址空间中，需要调用操作系统内核的方法为其把这段地址映射到当前的逻辑地址空间（一个函数，忘记叫什么，调用后修改 mmu，返回逻辑地址），从而在这个逻辑地址上运用偏移量操作

要注意，设备抽象并不一定要真的与某个设备绑定，所有的内核态程序（大概率就是驱动）都可以通过操作系统提供的函数来创建一个设备抽象。例如我就可以自己写一个驱动，在安装的时候创造一个虚拟的设备（Linux上有个 device_create 方法好像），也不需要什么信息，给个id就行，然后再把自己作为驱动注册到内核（要提供自己匹配的设备id，就用注册时提供的就可以），这样当用户程序使用设备描述符（在Linux下一切皆文件，所以会映射到一个文件，Windows下需要给出设备标识）进行读写操作的时候，内核就会调用我们的驱动（例如在Linux下，应用程序可以通过open来打开设备，我们的驱动就在打开的时候print一个字符串）

事实上，绝大多数的设备抽象都不是操作系统内核创建的，而是由设备驱动直接或间接的创建的

设备抽象的获取

上面的阐述中，我们说到驱动和设备是分离的，互相匹配的，所以驱动本身在安装的时候（非安装时期则不一样，看具体功能）多数不会创建设备抽象，而是匹配已有的设备抽象（这也符合规律，不然操作系统怎么能够内置那么多驱动）。那么问题就出现了，设备抽象怎么来呢

事实上，最初始的设备由BIOS提供。BIOS是主板的一部分，主板上具有大量的集成设备，这些设备由制造商制造，所以BIOS肯定里面有厂家写死的硬件信息。当然这些信息还不是操作系统中的设备抽象，只是信息而已，BIOS把这些信息存储在某个地方（SCPI好像），操作系统启动后立刻检索就能获得BIOS提供的信息并借此创建设备抽象

BIOS 作为一个程序，其内部内置了一些类似于驱动的逻辑，这些逻辑可以达到某些驱动的效果（比如键盘，磁盘，显示器）。BIOS其实只知道它所具有的那些接口，比如图像，它并不知道我们用的是什么显示器，它只是以一种约定俗成的格式向控制器寄存器存放数据；键盘也是类似，它只是能够监听 8 号中断（键盘都是8中断）并读取内容而已

当然现阶段的BIOS越来越复杂，尤其是现在还出现了更复杂的基础程序 UEFI（一般还叫BIOS），这使得其能力越来越复杂，甚至堪比一个小操作系统，例如可以使用鼠标，显卡

你可能还是会问：那么不是主板集成的设备从哪里来呢？这个并不简单。首先，计算机中的设备远远比我们想象的要多得多，用粗暴点的话说，“机箱里只要不是电线的地方，就是一个设备”（甚至更夸张，PCI总线中的电线属于PCI这个设备的一部分），真正可以说不是设备的部分大概只有cpu到内存这一段系统总线。举几个例子来理解哪些也是设备，cpu（cpu的驱动多数用于多核cpu的调用），PCI总线，PCI插槽，usb接口，磁盘设备控制器，磁盘，电源

我们知道，我们要添加新的设备肯定需要接口，那么答案就呼之欲出了：新的设备由接口的驱动创建。目前的接口设备的驱动都实现了其各自定义的通信协议，例如usb协议，由此我们就不难猜想这些接口是如何识别外部设备的了：当设备插入接口改变电气信号发生中断，设备中断驱动则根据协议访问设备的信息，进而使用信息创建设备，操作系统也由此匹配合适的驱动。有的协议甚至更加复杂，例如 usb协议 好像规定了设备可以自带驱动

总结

研究这些问题的初衷是由于想要理解虚拟化技术是如何模拟IO设备的，现在就有了结论，因为设备本身对于软件而言就是一个比较随意的概念，只需要宿主操作系统作为BIOS来提供设备信息并且设置好这些设备的驱动（printf!）就可以了