关于设备驱动程序的问题核心
目前，我的操作系统从软盘启动。由于软盘驱动程序已过时，我计划更改启动介质。
当我试图弄清楚要使用什么启动介质时，我意识到无论我选择什么，我都需要为其编写设备驱动程序。虽然实模式 BIOS 可能会为我提供一些中断来与该设备交互，但一旦进入保护模式，我就只能靠自己了。所以我开始阅读< Linux设备驱动程序第三版>>寻求一些指导。但这本书是关于为 Linux 系统编写设备驱动程序的。因此，这意味着设备驱动程序是特定于操作系统的。
现在我有以下问题：
- 设备驱动程序在哪些方面依赖于操作系统？
- 操作系统和设备驱动程序在内存中是如何布局的？
- 操作系统和设备驱动程序如何相互作用？
- 如果我热插拔设备，操作系统如何知道在哪里可以找到正确的设备驱动程序？
Currently, my OS boot from floppy. Since floppy driver is obsolete, i am planning to change the booting media.
As I try to figure out what booting media to use, I realize that no matter what I choose, I need to write device driver for it. Though the Real Mode BIOS may provide me with some interrupts to interact with that device, I am on my own once entered the Protected Mode. So I start to read the < Linux Device Driver 3rd edition > for some guide. But that book is about writing device driver for Linux system. So, that implies that device drivers are specific to operating system.
Now I got the following questions:
- In what aspects does a device driver depend on the operating system?
- How are the operating system and device drivers laid out in memory?
- How do the operating system and device drivers interact with each other?
- If I hot-plug in a device, how does the operating system know where to find the proper device driver?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
设备驱动程序是一段代码，用于实现设备和（通常）操作系统内核之间的接口。在这方面，它必然取决于它所针对的操作系统 - 这是核心目的，使操作系统了解设备并允许其使用其功能。
这并不是说设备驱动程序的代码不能在不同的操作系统上共享。它们的某些部分可以是可移植的（设备端），但接口端（与操作系统交互）取决于操作系统定义/提供的 API。
内存布局完全取决于系统。与其他内核服务相比，驱动程序不必有任何特定的内存布局策略。设备本身很可能会施加内存布局限制，但这是另一个主题。
操作系统定义了它如何通过 API 与设备驱动程序交互。您在那本（伟大的）书中找到了有关 Linux 如何实现这一点的文档。其他操作系统可以采取不同的做法——操作系统设计者设定规则。如果您是创建内核的人，则您可以定义 API。
热插拔并不容易。进行映射的一种方法是使用某种形式的查找表，其中来自设备的信息作为“键”，并使用合适的设备驱动程序结构/指针/任何内容作为值，或者反之亦然（在驱动程序中有一个 API让您知道可以处理哪些设备 ID）。设备 ID 可以是 PCI 设备 ID、USB 标识符……取决于总线和设备类型。
A device driver is a piece of code that implements the interface between a device and (usually) the operating system kernel. In that regard, it is necessarily dependent on the operating system it's targeted for - that's is core purpose, making that operating system aware of the device and allow it to use its functions.
This is not to say that code for a device driver can't be shared on different OSes. Some parts of them could be portable (the device side), but the interface side (that interacts with the OS) is dependent on the API that OS defines/provides.
Layout in memory is entirely system dependent. There doesn't have to be any specific memory layout policies for drivers versus other kernel services. The device itself might very well impose memory layout constraints, but that's a different topic.
The OS defines how it interacts with device drivers through APIs. You've got the documentation for how Linux does it in that (great) book. Other OSes could do it differently - the OS designers set the rules. If you're the one creating the kernel, you define the APIs.
Hot-plug is not easy. One way of doing mapping is to use some form of lookup table with information from the device as a "key", and the suitable device driver structure/pointer/whatever as the value, or the other way around (having an API in your drivers that lets you know what device IDs the can handle). Device IDs could be PCI devices IDs, USB identifiers, ... depends on the bus and type of device.