NeXTSTEPDRIVERKIT:Chapter1 7

I/O and Interrupt Requests

I/O 그리고 인터럽트 요청

Everything a driver does—whether or not it's a Driver Kit driver—is the result of one of two types of requests:
드라이버가 하는 모든 일(Driver Kit 드라이버 거나 아니거나)은 두 가지 유형의 요청 중 하나의 결과입니다:

• I/O requests (from a user-level program, the kernel, or another driver)
  I/O 요청(사용자 수준 프로그램, 커널 또는 다른 드라이버에서)
• Interrupt requests (from the hardware)
  인터럽트 요청(하드웨어에서)

Interrupt requests include "soft interrupts," such as timeout notifications. The Driver Kit thread-based design allows you to manage I/O requests and interrupts one at a time.
인터럽트 요청에는 시간 초과 알림과 같은 "soft interrupts" 가 포함됩니다. Driver Kit 의 스레드 기반 디자인을 사용하면 I/O 요청을 관리하고 한 번에 하나씩 인터럽트를 수행 할 수 있습니다.

I/O 스레드를 사용한 하드웨어 접근 예약(Scheduling Hardware Access with I/O Threads)

Different drivers have different requirements for ordering their accesses to the hardware. Driver Kit display drivers are very simple in this respect: they don't have to queue requests because the Window Server is the only process that makes requests, and it sends them one at a time. Display drivers may be particularly simple because on many systems, display hardware doesn't generate interrupts.
서로 다른 드라이버라면, 하드웨어 접근을 주문(ordering)하기 위한 각각 마다의 요구 사항을 가지고 있습니다. Driver Kit 디스플레이 드라이버는 이 점에서 매우 간단한데, Window Server 가 요청을 하는 유일한 프로세스이기 때문에 별도로 요청을 대기시킬 필요가 없으며 한 번에 하나씩 보냅니다. 많은 시스템에서 디스플레이 하드웨어가 인터럽트를 생성하지 않기 때문에 디스플레이 드라이버는 특히 간단할 수도 있습니다.

Other drivers have to be more careful. These drivers use an I/O thread—a single thread of execution that handles all access to a single hardware device. Some of the device classes, such as those for SCSI controllers, network, and sound devices, start up the default I/O thread for you.
다른 드라이버는 더 조심해야합니다. 다른 드라이버들은 단일 하드웨어 장치에 대한 모든 액세스를 처리하는 단일 실행 스레드인 I/O 스레드를 사용합니다. SCSI 컨트롤러, 네트워크 및 사운드 장치와 같은 일부 장치 클래스는 기본 I/O 스레드에서 시작합니다.

Typically, each driver instance has exactly one I/O thread. However, some drivers use a single I/O thread for more than one instance. What matters is that only one thread at a time has access to any particular hardware resource.
일반적으로 각 드라이버 인스턴스에는 정확히 하나씩의 I/O 스레드가 있습니다. 그러나 일부 드라이버는 둘 이상의 인스턴스에 대해 단일 I/O 스레드를 사용합니다. 하지만 중요한 점은 한 번에 하나의 스레드만 특정 하드웨어 자원에 액세스할 수 있다는 것입니다.

Note: Some hardware devices can handle more than one request at once. For example, some SCSI controllers can queue multiple commands.
Note: 일부 하드웨어 장치는 한 번에 둘 이상의 요청을 처리 할 수 ​​있습니다. 예를 들어, 일부 SCSI 컨트롤러는 여러 명령을 대기열에 넣을 수 있습니다.

At any given time, the I/O thread should be doing exactly one of two things:
주어진 시간에 I/O 스레드는 두 가지 중 하나만 정확하게 수행해야합니다:

• Waiting for an I/O request (from a user, the kernel, or another driver) or an interrupt message
  (사용자, 커널 또는 다른 드라이버로부터의)I/O 요청 또는 인터럽트 메시지에 대한 대기상태
• Executing (dealing with the hardware)
  실행상태(하드웨어 다루기)

Processes can use a variety of mechanisms to communicate I/O requests to the I/O thread. One of these mechanisms—Mach messages—is the same way the kernel informs the I/O thread that an interrupt has occurred. In this scheme, the kernel enqueues Mach messages for the I/O thread. When the I/O thread isn't executing a request, it dequeues the message and invokes an appropriate driver method in response. (You can also write a custom I/O thread to take whatever action you want in response to messages.) "Synchronizing with the I/O Thread" in Chapter 2 provides more details.
프로세스는 다양한 메커니즘을 사용해서 I/O 요청을 I/O 스레드에 전달할 수 있습니다. 이러한 구조(mechanisms)중 한가지인 Mach 메시지는, 인터럽트가 발생했다는 것을 커널이 I/O 스레드에 알리는 방법입니다. 이 체계에서 커널은 I/O 스레드에 대한 Mach 메시지를 대기열에 넣습니다. I/O 스레드가 요청을 실행하지 않을 때, I/O 스레드는 메시지를 대기열에서 제외하며 응답으로 적절한 드라이버 메소드를 호출합니다(사용자 정의 I/O 스레드를 작성해서, 메시지에 대한 응답으로 원하는 작업을 수행할 수도 있습니다). 2 장의 "Synchronizing with the I/O Thread" 에서 자세한 내용을 제공합니다.

The I/O thread model greatly simplifies driver development and lessens the time needed for debugging the driver. Only one thread deals with any hardware resource at a time, so it's not necessary to use locks and disable interrupts to protect access to hardware and data structures. The user thread communicates requests to the I/O thread, and commands can be enqueued for the I/O thread to execute. The driver can handle one request at a time—instead of many requests to access multiple resources at the same time.
I/O 스레드 모델은 드라이버 개발을 크게 단순화하며, 드라이버 디버깅에 필요한 시간을 줄여줍니다. 한 번에 하나의 스레드만 하드웨어 리소스를 처리하므로 하드웨어 및 데이터 구조에 대한 액세스를 보호하기 위해 잠금을 사용하거나 인터럽트를 비활성화할 필요가 없습니다. 사용자 스레드는 I/O 스레드에 요청을 전달하고, 명령을 실행해서, I/O 스레드가 실행될 수 있도록 큐에 넣을 수 있습니다. 드라이버는 동시에 여러 리소스에 접근 많은 요청 대신, 한 번에 하나의 요청을 처리 할 수 ​​있습니다.

인터럽트 서비스(Servicing Interrupts)

The Driver Kit has a simple scheme for servicing interrupts: The kernel notifies drivers of interrupts by sending them Mach messages. Each driver can receive these messages whenever it chooses, typically when it isn't executing any other requests.
Driver Kit 에는 인터럽트를 처리하는 간단한 구성(scheme)이 있습니다. 커널은 Mach 메시지를 보내서 인터럽트 드라이버에게 알립니다. 각 드라이버는 일반적으로 별도의 요청을 실행하지 않고 있을 때에는 메시지 수신을 선택할 수 있습니다.

The advantages of this scheme become clear when you consider an alternative—the traditional UNIX method of handling interrupts. Traditional UNIX drivers handle interrupts as soon as they happen—even if the driver is already executing an I/O request. Each driver registers an interrupt handling function that's called whenever the device interrupts. Some systems can't tell exactly which device interrupted, so they call several drivers' interrupt handlers until one accepts the interrupt. While an interrupt is being handled, nothing else in the system (except higher priority interrupt handlers) can execute.
이 체계의 장점은 인터럽트를 처리하는 전통적인 UNIX 방법의 대안을 고려하려 할 때 명확해집니다. 기존의 UNIX 드라이버는 드라이버가 이미 I/O 요청을 실행중 이더라도 인터럽트를 즉시 처리합니다. 각 드라이버는 장치가 인터럽트를 시도할 때마다 호출될 인터럽트 처리 함수를 등록합니다. 어떤 시스템은 어떤 장치가 인터럽트 되었는지 정확히 알 수 없기 때문에 인터럽트를 받아들일 때까지 여러 드라이버의 인터럽트 핸들러를 호출하기도 합니다. 인터럽트가 처리되는 동안 시스템의 다른 것(우선 순위가 높은 인터럽트 핸들러 제외)은 실행할 수 없습니다.

Under the traditional UNIX scheme, drivers can't control when interrupts occur. All they can do is control when interrupts don't occur by disabling interrupts. Drivers disable interrupts to protect critical sections of code, such as those that access hardware or access data structures that are also used by interrupt handlers. However, disabling interrupts has disadvantages:
기존의 UNIX 체계속에서 드라이버는 인터럽트 발생 시점을 제어할 수 없습니다. 할 수 있는 일은 인터럽트를 비활성화해서 인터럽트가 발생하지 않는 경우를 제어하는 ​​것 뿐입니다. 드라이버는 하드웨어를 접근하거나 인터럽트 처리기에서도 사용되는 데이터 구조에 접근하는 것등과 같은, 코드의 중요 섹션을 보호하기 위해서 인터럽트를 비활성화합니다. 그러나 인터럽트를 비활성화 한다면 단점이 생기게 됩니다:

• If a driver disables interrupts for too long, the consequences can be anything from reduced performance to system crashes or hangs.
  드라이버가 너무 오랫동안 인터럽트를 비활성화하면 성능 저하에서 부터 시스템 충돌 또는 중단에 이르는 결과가 발생할 수 있습니다.
• If a driver disables interrupts and, through some bug, fails to reenable them, the system will hang.
  드라이버가 인터럽트를 비활성화하고 버그를 통해 다시 활성화하지 못하면 시스템이 중단됩니다.
• It's easy to fail to protect a critical section—especially when you're changing code that someone else wrote—which can result in bugs that are hard to track down.
  특히 다른 사람이 작성한 코드를 변경하는 경우, 중요한 섹션을 보호하지 못하면 쉽게 추적할 수없는 버그가 발생될 수 있습니다.

The Driver Kit scheme of interrupt handling lets you choose when to handle interrupts, so you don't have to protect critical sections from interrupt handlers. This scheme works well with most hardware devices.
Driver Kit 체계의 인터럽트 처리를 사용하면 인터럽트 처리시점을 선택할 수 있으므로, 인터럽트 처리기에서 중요한 섹션을(별도로) 보호 할 필요가 없습니다. 이 체계는 대부분의 하드웨어 장치에서 잘 작동합니다.

IODirectDevice provides a default I/O thread that intercepts Mach interrupt messages and notifies drivers of them with Objective C messages. Driver objects are notified of interrupts with the interruptOccurred or interruptOccurredAt: message. See the sections "Interfacing with the Driver" and "Handling Interrupts" in Chapter 2 and the IODirectDevice class specification in Chapter 5 for more information.
IODirectDevice 는 Mach 인터럽트 메시지를 가로 채고 Objective C 메시지로 드라이버에 알리는 기본 I/O 스레드를 제공합니다. 드라이버 객체는 interruptOccurred 또는 interruptOccurredAt: 메시지를 사용해서 인터럽트를 알립니다. 자세한 내용은 2 장의 "Interfacing with the Driver" 및 "Handling Interrupts" 절 및 5 장의 IODirectDevice 클래스 지정 절을 참조하십시오.

A few devices require that interrupts be handled immediately. For example, a device might have a register that must be read within 50 microseconds of the interrupt occurring. On some devices data overruns occur if interrupts aren't handled quickly enough. In these cases, a kernel-level driver might need to register a direct interrupt handler—a function that's called as soon as the interrupt is detected. This function should perform any time-critical operations and, if necessary, send a Mach message so that the driver can further process the interrupt. The section "Custom Interrupt Handlers" in Chapter 2 describes how this interrupt handling function should work.
일부 장치에서는 인터럽트를 즉시 처리해야 합니다. 예를 들어, (어떤)장치에는 인터럽트 발생 후 50 마이크로초 이내에 읽어야 하는 레지스터가 있을 수 있습니다. 일부 장치에서는 인터럽트가 충분히 빠르게 처리되지 않으면 데이터 오버런(data overruns)이 발생합니다. 이러한 경우 커널 수준 드라이버는 직접 인터럽트 핸들러 (인터럽트가 감지되자마자 호출되는 함수)를 등록해야 할 수도 있습니다. 이 함수는 시간이 중요한 작업을 수행해야하며, 필요한 경우 드라이버가 인터럽트를 더 처리 할 수 ​​있도록 Mach 메시지를 보냅니다. 2 장의 "Custom Interrupt Handlers" 절은, 이러한 인터럽트 처리 기능이 작동하는 방법을 설명합니다.