OKL4 supports the management of hardware interrupts in two aspects by providing an abstraction of hardware operations and providing access control.
(OKL4는 하드웨어 동작의 추상화와 접근 제어를 제공함으로써 두가지 측면에서 하드웨어 인터럽트 관리를 지원한다.)
OKL4 defines a common interface to handle common interrupt-related platform-specific operations that must be performed on hardware. The interface includes operations such as enabling and disabling interrupts, the clearing and acknowledgement of interrupts, as well as defining the interrupt vector entry point. This interface is a part of the OKL4 Board Support Package (BSP).
(OKL4는 하드웨어상에서 동작해야만 하는 인터럽터 연관적인 플랫폼 특정 동작을 조작하기 위해서 일반적인 인터페이스를 정의한다. 인터페이스는 인터럽트 벡터 엔트리 포인터 정의뿐만 아니라,인터럽트의 활성화 그리고 비활성화, 인터럽터의 초기화와 받았음을 알림과 같은 동작들을 포함한다. 인터페이스는 OKL4 BSP의 한 부분이다.)
OKL4 uses the asynchronous inter-process communication(IPC) mechanism to delivery hardware interrupt to threads.
(OKL4는 하드웨어 인터럽트를 쓰레드들에게 전달하기 위해서 비동기 IPC 매커니즘을 사용한다.)
Each handler thread can register with the kernel for one or more asynchronous notification bits to be used to indicate pending interrupts. The OKL4 Board Support Package(BSP) defines an interrupt descriptor data structure. One or more interrupt descriptors reside in the UTCB of a handler thread. This descriptor is used by the BSP to indicate to the handler which interrupt(s) are currently pending.
(각 핸들러 쓰레드는 펜딩되고 있는(미해결되고 있는) 인터럽트들을 나타내는데 사용되어지기 위한 하나 그 이상의 비동기 통지 비트들을 위해 커널에 등록할 수 있다. OKL4 BSP는 인터럽터 디스크립터 데이터 구조체를 정의한다. 하나 그 이상의 인터럽터 디스크립터는 핸들러 쓰레드의 UTCB안에 존재한다. 이 디스크립터는 현재 펜딩되고 있는 인터럽트가 어느 것인지 핸들러에게 알려주기 위해서 BSP가 사용한다.)
In this design, the BSP is responsible for maintaining the mapping of interrupt sources to interrupt descriptor, and informing the kernel that a notification needs to be delivered to the handler. The BSP is required to determine the kernel thread and which notify bits needs to be updated when delivering an interrupt. The platform code updates the handlers interrupt descriptors and calls the generic kernel code to deliver the notify bits to the thread. The BSP may call this interface multiple times to deliver interrupts to multiple handlers. When all pending interrupts have been handled, the BSP calls the kernel scheduler to determine the next thread to run.
(이 디자인에서 BSP는 인터럽터 디스크립터와 인터럽터 소스들의 맵핑을 관리하고, 통지는 핸들러에게 전달되어야 한다는 것을 커널에게 통지하는 의무를 가진다. BSP는 커널쓰레드와 인터럽트가 전달될 때 어느 통지비트들이 업데이트되어야 하는지를 결정할 것을 요구받는다. 플랫폼코드는 핸들러들의 인터럽터 디스크립터를 업데이트하고, notify bits를 쓰레드에게 전달하기 위해서 일반적인 커널코드를 호출한다. BSP는 인터럽트를 여러 핸들러들에게 전송하기 위해서 이 인터페이스를 여러번 호출할지도 모른다. 모든 펜딩된 인터럽트가 처리되어질 때, BSP는 실행하기 위한 다음 쓰레드를 결정하기 위해서 커널 스케줄러를 호출한다.)
Delivering interrupts using asynchronous notification provides the handler the option of polling pending notify bits and interrupt descriptor(s). Note that this is supported at the discretion of the BSP. The handler thread may still be required to acknowledge these interrupts with the kernel to guarantee future delivery of these interrupts.
(비동기 통지를 이용하여 인터럽트를 전달하는 것은 계류중인(기다리는) Notify 비트들과 인터럽터 디스크립터를 폴링하는 옵션을 핸들러에게 제공한다. 이것은 BSP의 재량(결정권)에 따라서 제공된다는 것을 주의하라. 핸들러 쓰레드는 여전히 이들의 인터럽트의 미래 전달을 보장하기 위해서 이 인터럽트(커널고 함께???)를 받았다고 답장하는것을 요구받을 것이다.)
1. Interrupt Acknowledgement
A New dedicated system call, InterruptControl, will be added to perform acknowledgement of interrupts as well as registration of interrupts as describe below. Acknowledgement of interrupts is necessary in order to signal the hardware that the interrupt has been handled and can be unmasked.
(새로운 InterruptControl 전용 시스템 콜은 아래 기술된 인터럽터 등록과 마찬가지로 인터럽터의 응답을 수행하기 위해서 추가될 것이다. 인터럽트에 대한 응답은 인터럽트가 처리가 되었고 언마스크될 수 있다는 것을 하드웨어에게 신호를 보내기 위해서 필요하다.)
Acknowledgement of interrupts optionally allows a thread to wait for subsequent interrupts (equivalent to WaitNotify) within the same system call, allowing efficient interrupt handling.
(인터럽트 응답은 추가적으로 쓰레드에게 같은 시스템 콜내에서 다음의 인터럽터들을 기다리고, 효과적인 인터럽터 처리를 허용하는 것을 허용한다.)
Waiting for interrupts may also be performed using a L4_WaitNotify operation, though this does not acknowledge the hardware. This is only used in order to wait for an initial interrupt, or if interrupts do not require explicit acknowledgement. On some platforms, acknowledgement of interrupts may not be required (e.g.. edge triggered). The BSP has the discretion of determining whether acknowledgement of interrupts is required. Note that if pending interrupts are maintained by the BSP, acknowledgement of interrupts is likely to be required.
(또한 인터럽터 대기는 L4_WaitNotify 동작을 사용하여 수행되어질 수 있다. 비록, 이것은 하드웨어에 응답하지 않을지라도. 이것은 단지 최초 인터럽터를 기다리기 위해서 사용되거나, 또는 만약 인터럽트가 명백한 응답을 요구하지 않는다면 사용되어진다. 몇몇 플랫폼상에서는 인터럽터의 응답은 요구되지 않을 수도 있다(엣지트리거와 같은 경우). BSP는 인터럽터 응답이 요구되는지 결정하는 결정권을 가진다. 만약 대기하고 있는 인터럽터가 BSP에 의해서 유지 된다면, 인터럽트의 응답은 요구될 가능성이 높다.)
When performing an acknowledge operation using the InterruptControl system call, the caller is required to specify the interrupts to acknowledge. These are encoded in a set of one or more reply interrupt descriptors provided in the message registers. The kernel then calls the BSP code and provides these arguments for decoding. The BSP will acknowledge these interrupts and may inspect the hardware (or saved pending interrupts) for further pending interrupts at this time and deliver them to the handler. If an optional wait for pending interrupts is specified, the kernel will check if any of the calling thread’s registered notify are set and returns immediately if any are set. Otherwise, the calling thread blocks until it receives new notify bits.
(InterruptControl 시스템 콜을 사용하여 응답 동작을 수행할 때, 호출자는 응답을 하기 위해서 인터럽터를 명세하는 것이 요구된다. 이것들은 하나 그 이상의 메세지 레지스터안에 제공되는 응답 인터럽터 디스크립터들의 set으로 엔코드되어진다. 그리고나서 커널은 BSP 코드를 호출하고, 디코딩을 위해 이들의 인수들을 제공한다. BSP는 이들의 인터럽터들 응답할 것이고, 이 시점에서 추가 펜딩 인터럽터에 대해 하드웨어(또는 저장된 펜딩 인터럽트)를 검사할 수도 있다. 만약 펜딩 인터럽터에 대한 추가적인 대기가 명세 되어졌다면, 커널은 어떤 호출쓰레드의 등록된 통지가 설정있는지를 검사할 것이고, 만약 설정되었다면 즉시 반환한다. 반면에 호출 쓰레드는 새로운 통지비트를 받을때까지 대기한다.)
Security checks must efficiently determine whether the calling thread may acknowledge the reply interrupt descriptor(s). These checks must ensure that the caller’s address space has access to the specified interrupts to acknowledge. Access control to interrupts is described below.
(보안검사는 호출쓰레드가 인터럽터 디스크립터들을 응답할지 안할지를 능률적인(효과적인) 결정을 해야 한다. 이런 검사들은 반드시 호출자의 주소공간이 명시된 인터럽터에 응답하기 위한 접근을 가지는 것을 확실하게 해야 한다. 인터럽터 접근제어는 아래에 설명되어있다.)
Note that care must be taken when acknowledging interrupts from a thread other than the registered interrupt handler. If the optional wait for pending interrupts is requested, the calling thread will not be delivered pending interrupts for the handler thread.
(등록된 인터럽터 핸들러이외의 쓰레드로부터 인터럽터를 응답할때 조심해야하는 것을 주의하라. 만약 펜딩 인터럽터의 추가적인 대기가 요구되어진다면, 호출 쓰레드는 핸들러쓰레드로부터 펜딩 인터럽터를 전달받지 못할 것이다.)
2 Interrupt Access Control
All threads must be granted permission prior to using the InterruptControl system call to wait and acknowledge interrupts. The Elfweaver tool is used to grant address spaces access to interrupts at build time. Threads within the address space can then register and unregister as handlers to any interrupt for which the address space has access to.
(모든 쓰레드는 반드시 인터럽터를 기다리거나 응답하기 위해서 InterruptControl 시스템콜을 사용함에 앞서 허가가 승인되어야 한다. Elfweaver 툴은 빌드시점에 주소공간에 인터럽터에 접근하는 것을 승인하는데 사용되어진다. 주소공간안의 쓰레드들은 주소공간이 접근(접근권한)을 가지는 어떤 인터럽터를 처리하는 것으로 등록하거나 등록해제를 할 수 있다.)
It is up to the BSP to encode and store the interrupt to address space mappings. It also enforces the address space access rights. The BSP is required to perform these checks when registering and unregistering interrupts to handlers. The BSP is also required to perform checks during acknowledgement of interrupts to ensure that only authorized threads can acknowledge interrupts.
( ????. 또한 주소공간 접근 권한을 실시한다(?). BSP는 인터럽터에 핸들러를 등록하거나 등록을 해제할 때 이것들(주소공간접근권한)의 검사를 수행하는 것이 요구된다. 또한, BSP는 오직 인증된 쓰레드만이 인터럽터에 호출을 할 수 있는 것을 보증하기 위해서 인터럽터의 응답동안 검사를 수행하는 것이 요구되어진다.)
3 Interrupt Registration
Threads may register and unregister as interrupt handlers using the InterruptControl system call. Only one thread can be the handler for a particular interrupt at any one time. Note that the handler thread for a particular interrupt must be unregistered prior to registering a new interrupt handler thread for the same interrupt. Registration of a new handler will return an error if a handler already registered for that interrupt.
(쓰레드들은 InterruptControl 시스템콜을 사용하여 인터럽터 핸들러로써 등록하거나 등록해제를 할수도 있다. 오직 하나의 쓰레드만이 특정 인터럽트를 위해 어떤 한 시점에 핸들러가 될 수 있다. 특정 인터럽터의 핸들러 쓰레드는 같은 인터럽트를 위해 새로운 인터럽터 핸들러를 등록하기 위해서는 반드시 등록해제 되어야 한다는 것을 주의하라. 만약 인터럽터를 위해서 핸들러가 이미 등록되어 있다면, 새로운 핸들러의 등록은 에러를 반환할 것이다.)
댓글 없음:
댓글 쓰기