NAME | SYNOPSIS | API RESTRICTIONS | FEATURES | DESCRIPTION | EXTENDED DESCRIPTION | ATTRIBUTES | SEE ALSO
#include <dki/f_dki.h>KnError svIntrAttach(CpuIntr intr, CpuIntrHandler intrHandler, void * intrCookie, CpuIntrOps ** intrOps, CpuIntrId * intrId);
The function or functions documented here may not be used safely in all application contexts with all APIs provided in the ChorusOS 5.0 product.
See API(5FEA) for details.
DKI
Provides x86 interrupts management services.
For family processors, there are:
Exceptions are generated and detected by the processor when executing instructions, such as division by 0. These processor exceptions are classified as faults, traps, and aborts. Programmed exceptions are another type of exception generated by INTx instructions.
Interrupts are generated by events external to the processor, such as requests to service peripheral devices. There are two types of interrupts:
Maskable interrupts are received on the INTR input pin of the x86 processor. If the IF flag of the EFLAGS register is not set, maskable interrupts do not occur.
Non-maskable interrupts are received on the NMI input pin of the x86 processor. There is no mechanism to prevent non-maskable interrupts.
The DKI provides support for only for interrupts, and not for exceptions. The processor associates an identifying number with each different interrupt (non-maskable and maskable). This number is called a vector in the range from 0-255 with the range of 0-31 reserved for exceptions. The DKI associates an identifying numeric constant with each interrupt.
The following numeric constants are available:
NMI_INT (non-maskable).
INTR_BASE_NUMBER (maskable)
The DKI provides support for 64 interrupts, ranging from INTR_BASE_NUMBER to INTR_BASE_NUMBER + 64.
The DKI provides services to allow host bus drivers to manage ix86 interrupts, mainly to attach/detach handlers to/from these interrupts.
svIntrAttach() attaches a handler to a given CPU interrupt.
The intr argument specifies the interrupt to which to attach.
The intrHandler argument specifies the handler to call back when the specified interrupt occurs.
The intrCookie argument specifies a parameter to pass back to the handler when called. It is opaque to the microkernel.
On success, K_OK is returned and services defined on the attached interrupt are returned in the intrOps parameter. An identifier for the attached interrupt is also returned in intrId . This identifier must be used as the first parameter to further calls to intrOps services.
Services available on an attached interrupt are defined by the CpuIntrOps structure as follows:
typedef struct CpuIntrOps { void (*enable) (CpuIntrId intrId); void (*disable) (CpuIntrId intrId); } CpuIntrOps;
The CpuIntrOps.enable routine enables the interrupt at CPU level identified by intrId .
The CpuIntrOps.disable routine disables the interrupt at CPU level identified by intrId .
NMI_INT is a non-maskable interrupt. Thus, CpuIntrOps.enable and CpuIntrOps.disable have no effect on these interrupts.
All other interrupts are masked using the same bit on an x86 processor EFLAGS register. Thus there is no way to enable or disable a single interrupt separately from the others.
When an interrupt occurs, the attached CpuIntrHandler is invoked with interrupts masked at processor level. This produces the same effect as if imsIntrMask_f() was called just prior to invoking the handler ( imsIntrMaskCount_f() is positive). Two parameters are passed to this handler:
Provided intrCookie parameter
Detected intr
It is up to the called interrupt handler to use CpuIntrOps.enable to allow or disallow interrupt nesting.
Typically, a host bus driver handler should handle x86 external interrupts as follows:
Enable interrupts at processor level ( CpuIntrOps.enable ).
Call handler(s) attached to the identified CPU interrupt.
Optionally, CpuIntrOps.disable interrupts to perform critical tasks, such as notifying the end an of interrupt to a PIC .
Return to the DKI .
On failure, an error code is returned as follows:
The interrupt specified in intr is invalid (not in the list above). Or, the interrupt specified in intr is valid, but a handler is already attached to it.
svIntrDetach() detaches an interrupt handler previously connected by svIntrAttach() .
The intrId argument identifies the attached interrupt handler, and was previously returned by svIntrAttach() .
svIntrCtxGet() retrieves the current level interrupt context. It is mainly to be used for profiling purposes.
On success, K_OK is returned and a pointer to the current level of interrupt saved context is returned in the intrCtx argument. The CPU context saved on interrupt contains the interrupted PC composed of the eip and cs registers, the EFLAGS register, and the stack pointer.
On failure, an error code is returned as follows:
Interrupt level is zero (not called from an interrupt handler).
There is no context available for the currently handled interrupt.
The table below specifies the contexts in which a caller is allowed to invoke each services.
Services | Base level | DKI thread | Interrupt | Blocking |
---|---|---|---|---|
svIntrAttach() | + | + | - | + |
CpuIntrOps.enable | + | + | + | - |
CpuIntrOps.disable | + | + | + | - |
svIntrDetach() | + | + | - | + |
svIntrCtxGet() | - | - | + | - |
See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
---|---|
Interface Stability | Evolving |
NAME | SYNOPSIS | API RESTRICTIONS | FEATURES | DESCRIPTION | EXTENDED DESCRIPTION | ATTRIBUTES | SEE ALSO