了解操作系统如何存储/检索IO设备输入
我对I/O设备（例如键盘）如何存储其输入以供操作系统或应用程序使用。如果我有一台具有单个处理器的计算机（一个带有单个核心的CPU），而当前的执行过程是游戏，那么游戏如何“意识到”键盘输入？即使按键迫使硬件中断（从而强制上下文切换），然后在操作系统将控制权重新回到游戏过程时“馈送”游戏的关键值，也无法保证游戏循环甚至会是当时检查玩家输入，它也很可能是更新游戏对象位置或渲染游戏世界。
因此，我的问题是...
- i/o设备（例如键盘存储）在其中输入到某种板载硬件特定的微处理器或板载内存存储缓冲区队列，后来可以“读取”并通过外部进程或外部流程刷新操作系统本身？非常感谢任何见解，谢谢！
I am a bit confused on how I/O devices like keyboards store their input for use by the operating system or an application. If I have a computer with a single processor (a CPU with a single core), and the current executing process is a game, how is the game able to be "aware" of keyboard input? Even if a key press were to force a hardware interrupt (and thus context switch), and then "feed" the key value to the game whenever the OS gives control back to the game process, there's no guarantee that the game loop would even be checking for player input at that time, it could just as well be updating game object positions or rendering the game world.
So my question is this...
- Do I/O devices like keyboards store there input to some kind of on-board hardware specific microprocessors or on-board memory storage buffer queues, which can later be "read" and flushed by external processes or the OS itself? Any insight is greatly appreciated, thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
让我们将其分为3个部分。
旧键盘的设备特定部分
（USB之前）；键盘中的微控制器定期扫描开关网格并检测何时按下键或释放键，将其转换为代码（可能是多个字节），然后一次将代码发送到计算机。该计算机还具有一些微控制器来接收这些字节。该微控制器具有1个字节缓冲液（甚至不够大，用于多字节代码）。
对于新键盘（USB）；键盘的内部大部分是相同的（微控制器扫描开关等等）；但是USB控制器问键盘“发生任何事情吗？”定期（通常每8毫秒）和键盘的微控制器回复。
无论如何；键盘驱动程序获取来自键盘的代码并对其进行处理；通常将其转换为固定的长度“密钥代码”，将其与其他数据合并（如果是shift或capslock或...当时处于活动状态；如果有unicode codepoint/s对密钥有意义，等等）和捆绑这是数据结构。
OS特定部分，
数据结构（由键盘驱动程序创建）通常由OS标准化为“用户输入事件”（因此，键盘，鼠标，触摸屏，相同的“事件”数据结构，操纵杆， ...）。
该“用户输入事件”是从驱动程序发送的。某种形式的过程间通信（管道，消息等）（例如GUI）。此过程间通信具有2种常见行为 - 如果接收程序被阻止等待接收事件，则调度程序将其解开（取消等待等待）并将其调度以使CPU再次获得时间；而且，如果接收程序不在等待，通常将事件放在待处理事件的队列（内存）中。
当然，通常涉及许多过程，“用户输入事件”可能会从一个过程（例如输入方法编辑器）转发到另一个过程（例如GUI）到另一个过程（例如，无论哪个窗口具有键盘焦点）。此外（对于旧的旧命令行），它可能最终进入翻译层（例如终端模拟器），该翻译层将事件转换为字符流（
stdin>），同时销毁大多数信息（例如，当键已发布）。语言特定部分
是从高级代码中获取事件的，这取决于语言是什么，有时还可以使用哪个库。最常见的是某种“ getEvent（）”，它导致程序从其队列（从内存）中获取下一个事件；如果没有任何事件，则可能导致程序等待（并且不使用任何CPU时间）。但是，通常会进一步埋葬，以便您注册回调，然后当其他称为“ getEvent（）”时，即使接收到一个为调用您已注册的回调时；因此，它可能最终像（例如Java）
public boolean handlevent（event evt）{switch（evt.id）{case event.key_press：...。Let's split it into 3 parts..
The Device Specific Part
For old keyboards (before USB); a microcontroller in the keyboard regularly scans a grid of switches and detects when a key is pressed or released, converts that into a code (which could be multiple bytes), then sends the code on byte at a time to the computer. The computer also has a little microcontroller to receive these bytes. That microcontroller has a 1 byte buffer (not even big enough for multi-byte codes).
For newer keyboards (USB); the keyboard's internals a mostly the same (microcontroller scanning a grid of switches, etc); but USB controller asks the keyboard "Anything happen?" regularly (typically every 8 milliseconds) and the keyboard's microcontroller replies.
In any case; the keyboard driver gets the code that came from the keyboard and processes it; typically converting it into a fixed length "key code", merging it with other data (if shift or capslock or... was active at the time; if there's unicode codepoint/s that make sense for the key, etc) and bundles all that into a data structure.
The OS Specific Part
That data structure (created by the keyboard driver) is typically standardized by the OS as a "user input event" (so, same "event" data structure for keyboard, mouse, touchscreen, joystick, ...).
That "user input event" is sent from driver via. some form of inter-process communication (pipes, messages, ...) to something else (e.g. GUI). This inter-process communication has 2 common behaviors - if the receiving program is blocked waiting to receive an event then the scheduler unblocks it (cancels the waiting) and schedules it to get CPU time again; and if the receiving program isn't waiting the event is often put on a queue (in memory) of pending events.
Of course often there's many processes involved, and the "user input event" might be forwarded from one process (e.g. input method editor) to another process (e.g. GUI) to another process (e.g. whichever window has keyboard focus). Also (for old legacy command line stuff) it might end up at a translation layer (e.g. terminal emulator) that converts the events into a character stream (
stdin) while destroying most of the information (e.g. when a key is released).The Language Specific Part
To get the event from high level code, it depends what the language is and sometimes also which library is being used. The most common is some kind of "getEvent()" that causes the program to fetch the next event from its queue (from memory); and may cause the program to wait (and not use any CPU time) if there isn't any event get yet. However, often that is buried further, such that you register a callback and then when something else calls "getEvent()" and when it receives an even it calls the callback you registered; so it might end up like (e.g. for Java)
public boolean handleEvent(Event evt) { switch (evt.id) { case Event.KEY_PRESS: ....键盘今天主要是USB。在包括ARM计算机在内的大多数计算机上，您都有一个USB控制器，该USB控制器实现了由多家主要科技公司开发的XHCI规范。如果您Google Google“ XHCI Intel Spec”或类似的内容，则第一个链接左右应该是指向完整规范的链接。
XHCI规格要求实现以PCI设备的形式。 PCI是由PCI-SEG组开发的另一种规格。该规范将所有内容指定为硬件要求。它不是XHCI的免费规格。实际上，获得（约3K $）非常昂贵。
OS使用ACPI或类似规格检测PCI设备，这些设备有时可能是板特定的（尤其是ARM，因为所有基于X86的计算机都实现了ACPI）。 ACPI表，在RAM的常规位置上找到，提及在哪里找到每个PCI设备的内存映射配置空间的基础地址。
OS使用在RAM中映射的内存的寄存器与PCI设备进行交互。操作系统在ACPI表指定的位置和配置空间本身以收集有关某个设备的信息并使设备代表其执行操作。 PCI设备的配置空间具有一般部分（每个设备相同）和一个更具体的部分（依赖设备）。在一般部分中，有一些条寄存器包含配置空间的设备依赖部分的地址。约定的每个实施者都可以使用特定于设备的部分来执行他们想要的任何操作。每个设备的一般部分必须有些相似，以便OS可以正确检测和初始化设备。
如今，每种类型的设备都必须尊重某些约定，以与当前的计算机一起使用。例如，硬盘将实现SATA，董事会将拥有AHCI（PCI SATA控制器）。同样，键盘将实施USB，并且董事会具有XHCI。
XHCI本身具有复杂的相互作用机制。键盘的摘要是，OS将“激活”键盘端点中的中断。然后，操作系统将在RAM中的圆环上放置传输请求（TRB）。对于中断端点，XHCI将在特定XHCI寄存器中指定的每个时间间隔读取一个传输请求。当Xhci执行TRB（进行传输时）时，它会将事件张贴到RAM中的另一个圆形环，称为事件环。当发布新事件时，XHCI会触发中断。在中断处理程序中，操作系统将读取事件戒指以确定发生了什么。对于键盘，操作系统可能会看到传输已完成并阅读数据。大多数情况下，键盘将返回8个字节。每个字节的解释是在转移时按下按键的键。字节包含常规的scancodes。因此，它们不直接采用UTF-8或ASCII格式。每个键盘键有一个Scancode。根据键盘键确定该怎么做，可以确定操作系统。例如，如果数据显示按下“ A”键，则操作系统可以查看是否按下“移位”键以确定“ A”是否应为大写或小写。如果下一份报告说未按下“ A”密钥，则应将其视为键的发布（用户释放了密钥）。换句话说，键盘在某些时间间隔内通过OS进行轮询。
中断处理程序可能会将密钥传递到内核的其他部分，并将密钥保存到特定过程结构中。该过程可能会轮询包含事件的锁定缓冲区。它也可能是一个仅包含所有事件的系统宽缓冲区。
较高级别的实现可能在OS之间有所不同。如果您了解较低级别的内部工作，那么您可能想象的是操作系统将如何工作。可以肯定的是，整个过程非常复杂，因为当今CPU具有多种核心，缓存以及其他复杂的机制。操作系统必须确保与所有这些机制无缝地工作，因此它非常复杂，但可以实现。要了解整个过程，您可能需要了解整个操作系统。它在其他操作系统概念中有很多后果。
The keyboards are mostly USB today. On most computers, including ARM computers, you have a USB controller implementing the xHCI specification developed by several major tech companies. If you google "xhci intel spec" or something similar, the first link or so should be a link to the full specification.
The xHCI spec requires implementations to be in the form of a PCI device. PCI is another spec which is developed by the PCI-Seg group. This spec specifies everything down to hardware requirements. It is not a free spec like xHCI. It is actually quite expensive to obtain (around 3k$).
The OS detects PCI devices using ACPI or similar specifications which can sometimes be board specific (especially for ARM because all x86 based computers implement ACPI). ACPI tables, found at conventionnal positions of RAM, mention where to find base addresses of the memory mapped configuration space of each PCI device.
The OS interacts with PCI devices using registers that are memory mapped in RAM. The OS reads/writes at the positions specified by ACPI tables and by the configuration spaces themselves to gather information about a certain device and to make the device do operations on its behalf. The configuration space of a PCI device have a general portion (the same for every device) and a more specific portion (device dependent). In the general portion, there are BAR registers that contain the address of the device dependent portion of the config space. Each implementer of the convention can do whatever they want with the device specific portion. The general portion must be somewhat similar for every device so that the OS can properly detect and initialize the device.
Today, each type of device have to respect a certain convention to work with current computers. For example, hard-disks will implement SATA and the board will have an AHCI (a PCI SATA controller). Similarly, keyboards will implement USB and the board has an xHCI.
The xHCI itself have complex interaction mechanisms. A summary for keyboards, is that the OS will "activate" the interrupt IN endpoint of the keyboard. The OS will then place transfer requests (TRBs) on a circular ring in RAM. For interrupt endpoints, the xHCI will read one transfer request per time interval specified by the OS in a specific xHCI register. When the xHCI executes a TRB (when it does the transfer), it will post an event to another circular ring in RAM called the Event Ring. When a new event is posted, the xHCI triggers an interrupt. In the interrupt handler, the OS will read the Event Ring to determine what happened. For a keyboard, the OS will probably see that a transfer was done and read the data. Most often, keyboards will return 8 bytes. Interpretation of each byte is the keys that were pressed at the moment of the transfer. The bytes contain conventional scancodes. So they are not directly in UTF-8 or ASCII format. There is one scancode per keyboard key. It is up to the OS to determine what to do depending on the keyboard key. For example, if the data says that the 'A' key is pressed, then the OS can look if the 'SHIFT' key is pressed to determine if the 'A' should be uppercase or lowercase. If the next report says that the 'A' key is not pressed than the OS should consider this as a release of the key (the user released the key). In other words, the keyboard is polled by the OS at certain intervals.
The interrupt handler will probably pass the key to other portions of the kernel and save the key to a process specific structure. The process will probably poll a lock protected buffer that will contain events. It could also be a system wide buffer that simply contains all events.
The higher level implementation probably varies between OS. If you understand the lower level inner workings than you can probably imagine how an OS will work. It is certain that the whole things is very complex because CPUs nowadays have several cores and caches and other complex mechanisms. The OS must make sure to work seamlessly with all these mechanisms so it is quite complex but achievable. To understand the whole thing, you'd probably need to understand the whole OS. It has lots of ramifications in other OS concepts.