NeXTSTEPDRIVERKIT:Chapter1 3

Driver Structure

드라이버 구조

To appreciate the structural simplicity of a Driver Kit driver, first consider how standard UNIX drivers are constructed.
Driver Kit 드라이버의 구조적 단순성을 이해하려면 먼저 표준 UNIX 드라이버가 구축되는 방법을 고려하십시오.

UNIX 드라이버 아키텍처

A UNIX driver has a "top-half" that is accessed through the system call interface and runs in the kernel on behalf of a user process. It manages the driver state and initiates data transfers. The "bottom- half" runs at interrupt level since it's driven by interrupts caused by data transfer completion or other asynchronous events. Interrupts are handled by the driver's interrupt handler, which may call top-half routines at interrupt priorities. Indirect devices—devices that are not directly connected to the processor, such as secondary-bus devices or SCSI peripherals—are each handled in an individual fashion—there's no systematic way to treat them.
UNIX 드라이버에는 시스템 호출 인터페이스를 통해 접근되고 사용자 프로세스를 대신하여 커널에서 실행되는 "top-half" 가 있습니다. 드라이버 상태를 관리하고 데이터 전송을 시작합니다. "bottom-half" 는 데이터 전송 완료 또는 다른 비동기 이벤트로 인한 인터럽트로 인해 인터럽트 수준에서 실행됩니다. 인터럽트는 인터럽트 우선 순위에서 최상위 루틴을 호출할 수 있는 드라이버 인터럽트 핸들러에 의해 처리됩니다. 간접 장치는 2 차 버스 장치 또는 SCSI 주변 장치와 같이 프로세서에 직접 연결되지 않은 장치는 각각 개별적인 방식으로 처리되며, 그 스스로를 처리할 체계적인 방법은 가지고 있지 않습니다.

This design paradigm has several consequences:
이 디자인 패러다임에는 여러 가지 결과가 있습니다:

• Multiple requests may attempt to access the same hardware or driver data structures at the same time.
  여러 요청은 동일한 하드웨어 또는 드라이버 데이터 구조에 동시에 접근을 시도 할 수 있습니다.
• Interrupts may occur at any time, and their handlers may also need to access hardware or data structures.
  인터럽트는 언제든지 발생될 수 있으며 핸들러는 하드웨어 또는 데이터 구조에 접근해야 할 수도 있습니다.

To coordinate access to these hardware and data resources, the driver must use such tactics as disabling interrupts, changing processor priority, and engaging locks of various types. The resulting code is often complicated: difficult to write, debug, understand, and maintain.
이러한 하드웨어 및 데이터 리소스에 대한 접근을 조정하려면, 드라이버가 인터럽트를 비활성화하고 프로세서 우선 순위를 변경하며 다양한 유형의 lock 을 설정하는 등의 전략을 사용해야합니다. 결과 코드는 종종 복잡하며 쓰기, 디버그, 이해 및 유지가 어렵기도 합니다.

Driver Kit 드라이버 아키텍처

You can write a UNIX style driver with the Driver Kit, but that's not the best way to go about it. Driver Kit drivers differ significantly from traditional UNIX or MS-DOS drivers. Driver Kit drivers have these characteristics:
Driver Kit 을 사용해서 UNIX 스타일의 드라이버를 작성할 수는 있지만 가장 좋은 방법은 아닙니다. Driver Kit 드라이버는 기존 UNIX 또는 MS-DOS 드라이버와 크게 다릅니다. Driver Kit 드라이버에는 이러한 특성이 있습니다:

• Drivers are objects. The Driver Kit is written in the Objective C language, which supports object-oriented programming. This programming approach also allows code that's common to all drivers—or a set of drivers such as network drivers—to be written once and inherited by subclasses.
  드라이버와 객체. Driver Kit 은 객체 지향 프로그래밍을 지원하는 Objective C 언어로 작성되었습니다. 이 프로그래밍 방식을 사용하면 모든 드라이버(또는 네트워크 드라이버와 같은 일련의 드라이버)에 공통된 코드를 한 번 작성하고 하위 클래스에서 상속받을 수 있습니다.
• By default, each driver uses only one thread—the I/O thread—to access its hardware device. All I/O threads reside in a separate kernel task—the I/O kernel task.
  기본적으로 각 드라이버는 하나의 스레드(I/O thread)만 사용하여 해당 하드웨어 장치에 접근합니다. 모든 I/O 스레드는 별도의 커널 태스크(I/O kernel task)에 존재합니다.
• By default, there's one I/O thread for each hardware device. Given any hardware resource, only one thread deals with that resource at a time. Traditional device drivers use locks and disable interrupts to protect access to hardware and data structures. Limiting resource access to only one thread greatly simplifies driver design.
  기본적으로 각 하드웨어 장치에 대해 하나의 I/O 스레드가 있습니다. 하드웨어 자원이 주어지면 한 번에 하나의 스레드만 해당 자원을 처리합니다. 기존의 장치 드라이버는 lock 을 사용하며 인터럽트를 비활성화해서 하드웨어 및 데이터 구조에 대한 액세스를 보호합니다. 하나의 스레드 한정으로 리소스 액세스를 제한하면 드라이버 설계는 크게 단순 해집니다.
• Interface methods in the driver are invoked from the user thread: the thread running in the kernel on behalf of the user. These methods communicate requests to the I/O thread using techniques such as Mach messaging, and they enqueue commands for the I/O thread to execute. The I/O thread can then handle one request at a time instead of being subjected to a barrage of requests to access multiple resources at the same time. (Interface methods don't perform I/O requests directly, because only the I/O thread should touch hardware and other critical resources.)
  드라이버의 인터페이스 메서드는 사용자 스레드에서 호출되며, 스레드는 사용자 대신(not a user side) 커널에서 실행됩니다. 이 메소드는 Mach 메시지와 같은 기술을 사용해서 I/O 스레드에 요청을 전달하고, I/O 스레드가 실행하도록 명령을 대기열에 추가합니다. 이후에 I/O 스레드는 동시에 여러 리소스에 접근하라는 요청을 처리하는 대신, 한 번에 하나의 요청을 처리 할 수 ​​있습니다. (오직 I/O 스레드만 하드웨어 및 기타 중요한 리소스와 접촉해야 하기 때문에, 인터페이스 메서드는 I/O 요청을 직접 수행하지 않습니다.)

Note: Mach messages are not the same as Objective C messages that are sent to objects. Mach messaging refers to use of the Mach operating system's message system. See the references on the Mach operating system and the Objective C language in the "Suggested Reading" section of the Appendix.
Note: Mach 메시지는 객체에 전송되는 Objective C 메시지와는 다릅니다. Mach 메시지는 마하 (Mach) 운영 체제의 메시지 시스템을 사용하는 것을 말합니다. 부록의 "Suggested Reading" 섹션에서 Mach 운영 체제 및 Objective C 언어에 대한 참조를 참조하십시오.

• The kernel takes all interrupts and notifies the I/O thread via Mach messages. Drivers don't need to run with interrupts disabled. The Driver Kit's thread-based model lets the driver delay responding to interrupts until it's ready to deal with them. The UNIX concept of a direct interrupt handler—a section of driver code that executes as soon as an interrupt is detected by the kernel—has been replaced by this Mach messaging mechanism. Interrupt handling is discussed in greater detail in "Servicing Interrupts" in this chapter. You can register your own interrupt handler if that's required, but unless you do, your driver will run at the user or I/O thread level—not at interrupt level.
  커널은 모든 인터럽트를 가진 후에 Mach 메시지를 통해 I/O 스레드에 알립니다. 드라이버는 인터럽트가 비활성화된 채로 실행해야할 필요가 없습니다. Driver Kit 의 스레드 기반 모델은 드라이버가 처리할 준비가 될 때까지 인터럽트에 응답하는 것을 지연시킵니다. 직접 인터럽트 처리기 방식(인터럽트가 커널에 의해 감지 되자마자 실행되는 드라이버 코드 섹션)의 UNIX 개념은 이 Mach 메시징 메커니즘으로 대체되었습니다. 필요한 경우 자신의 인터럽트 핸들러를 등록할 수는 있습니다만, 그렇게 하지 않으면 드라이버가 (인터럽트 수준이 아닌) 사용자 또는 I/O 스레드 수준에서 실행됩니다.
• Drivers for devices that are connected to the processor indirectly through some secondary bus—such as SCSI peripherals connected to a SCSI bus—have a structured way to communicate with the drivers controlling the secondary bus. For example, SCSI controller objects conform to an Objective C protocol that SCSI peripheral drivers can employ.
  일부 보조 버스(SCSI 버스에 연결된 SCSI 주변 장치)를 통해 간접적으로 프로세서에 연결된 장치용의 드라이버는 보조 버스를 제어하는 ​​드라이버와 통신할 수 있는 구조화 된 방식을 취합니다. 예를 들어 SCSI 컨트롤러 개체는 SCSI 주변 장치 드라이버가 사용할 수있는 Objective C 프로토콜을 준수합니다.
• Driver Kit drivers are currently kernel-level drivers, either as loadable kernel servers or as part of the kernel supplied by NeXT. User-level drivers are not yet supported.
  Driver Kit 드라이버는 현재 로드 가능한 커널 서버 또는 NeXT 가 제공하는 커널의 일부인 커널 수준 드라이버입니다. 사용자 수준 드라이버는 아직 지원되지 않습니다.

Tip: Running drivers at user level would make testing hardware much easier, and it would greatly reduce the likelihood of system panics due to driver bugs. This design goal hasn't been realized yet. However, when you design your driver, you should keep in mind the possibility of it becoming a user-level driver. To make porting drivers from kernel to user level as easy as possible, much of the Driver Kit API is identical at kernel level and at user level. In future releases, the goal is to allow all drivers to run at user level.
Tip: 사용자 수준에서 드라이버를 실행하면 하드웨어 테스트 하기가 훨씬 쉬워지며, 드라이버 버그로 인해 시스템 패닉이 발생할 가능성이 크게 줄어 듭니다. 이 설계 목표는 아직 실현되지 않았습니다. 그러나 드라이버를 디자인 할 때는 사용자 수준의 드라이버가 될 수 있다는 점을 염두에 두어야합니다. 가능한한 커널에서 사용자 수준으로 이식하는 드라이버를 만들기 위해 Driver Kit API 의 대부분은 커널 수준과 사용자 수준에서 동일하게 되어 있습니다.

Although it's possible to write a UNIX style driver with the Driver Kit, that's not the best way to proceed. You wouldn't be taking full advantage of the capabilities of the Driver Kit, and you would be doing a lot of extra work.
Driver Kit 을 사용해서 UNIX 스타일의 드라이버를 작성할 수는 있지만 최선의 방법은 아닙니다. 드라이버 키트의 기능을 최대한 활용하지 못하면 많은 추가 작업을 수행해야 합니다.