JPH08272727A - System event processing mechanism - Google Patents

Abstract

PURPOSE: To easily add and alter a system event processing to an operating system. CONSTITUTION: An interruption dispatch table 1 which is provided hitherto to process a hardware device interruption is provided newly with a part which accepts a software interruption 3. For the hardware device interruption 2, the corresponding device driver 3 is actuated and for the software interruption 3, the corresponding event handler 5 is actuated. The event handler 5 is equivalent to the device driver 4 and the event handler for a system event can easily be added and altered without altering the operating system.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a system event processing mechanism utilizing the processing mechanism of an interrupt driven device driver in an operating system.

[0002]

2. Description of the Related Art In an operating system (OS) that performs basic control of a computer system, system events except a specific event from a hardware device are handled by a processing routine prepared in a kernel section. As a result, operating systems are typically programmed with various system events that are appropriate for the application being executed,
It is created at a high development cost.

[0003]

However, the conventional system event processing mechanism as described above has the following problems to be solved. With the development of many advanced application programs, the operating system side is also required to improve to provide a comfortable operating environment. However, since the configuration of the conventional operating system is extremely complicated, it is difficult to make a simple change in the kernel part and additionally change the system event handler. Even if it could be done, making changes to the kernel part of the operating system would change the core part of the system, and its impact on the entire system is not easy. On the other hand, nowadays, when a more advanced man-machine interface is required, it is required to easily add a system event handler to such an operating system to enable various additional changes.

[0004]

The present invention adopts the following constitution in order to solve the above problems. An interrupt dispatch table that accepts both hardware device interrupts and software interrupts, and a device driver that is activated when a hardware device interrupt is accepted by this interrupt dispatch table and that is prepared to correspond to the corresponding hardware. The interrupt dispatch table includes an event handler that is activated when a software device interrupt is accepted and is prepared so as to correspond to the corresponding software and has the same configuration as the device driver.

[0005]

With respect to the interrupt dispatch table conventionally provided for processing a hardware device interrupt, a new part for accepting a software interrupt is provided. Then, for a hardware device interrupt, a corresponding device driver is activated, and for a software interrupt, a corresponding event handler is activated. Event handlers are equivalent to device drivers. This makes it easy to add and change event handlers for system events without changing the operating system.

[0006]

The present invention will be described in detail below with reference to the embodiments shown in the drawings. FIG. 1 is a block diagram showing an embodiment of a system event processing mechanism of the present invention. This mechanism uses an interrupt driven device driver that has been conventionally used to handle hardware device interrupts. That is, the hardware device interrupt 2 can be accepted for the interrupt dispatch table 1 for that purpose, and
Enables acceptance of software interrupt 3. For the hardware device interrupt 2, it corresponds to the device number entered in the interrupt dispatch table 1,
The device driver 4 is assigned. Further, for software interrupt 3, for event numbers 1 to N entered in the interrupt dispatch table 1,
Each has an event handler 5.

The basic structure of the interrupt dispatch table 1 itself is the same as that of the conventional one, and only the extended part that enables event entry is different. The event handler 5 is completely equivalent to the device driver 4 and is composed of a program that processes the event in the same operation as the device driver 4 in response to a software interrupt. The interrupt dispatch table 1 sets the number of hardware device interrupts and the number of software interrupts to be entered in advance to predetermined values, and the number of event handlers can be increased or decreased within this range. Moreover, in this case, the operating system itself does not need to be changed.

FIG. 2 shows a flow chart of an event handler registration operation according to the present invention. According to the present invention, it is possible to freely add and change the event handler without changing the kernel part of the operating system.
In this case, the processing is performed as shown in this flowchart. That is, when a process for a new system event is proposed in step S1, it is checked in step S2 whether an entry can be additionally registered in the interrupt dispatch table 1. If there is room in the table and additional registration of the event is possible, step S3
Then, the process proceeds to step S4, and the event handler 5 is registered. If you cannot register, you cannot add until there is space. In addition, in the case of a change, the event handler that has been registered so far is deleted, so that a vacancy naturally occurs.

FIG. 3 shows a block diagram of a comparative example for comparison with the present invention. In the conventional operation system 7 shown in this figure, an event handler 9 for processing the system event 6 is built in the kernel unit 8. In the conventional operation system 7 as described above, even if only the event handler 9 is added and changed, the whole operation may be affected, and the addition and change work is not easy. For example, when the operating system operates in response to the request of the application program,
Software interrupts often occur at the interface portion. If it is easy to add and change the portion that processes this, it is possible to appropriately meet the request of the application program. According to the system event processing mechanism of the present invention described so far, it is possible to easily add and change event handlers, which greatly contributes to system upgrade and man-machine interface improvement.

[0010]

According to the system event processing mechanism of the present invention described above, an interrupt dispatch table for accepting a hardware device interrupt and a software interrupt is provided, and a device driver corresponding to the hardware device interrupt is activated by this. Since an event handler having a configuration equivalent to this device driver is activated in response to a software interrupt, it is possible to easily add and change the event handler without changing the operating system. Therefore, it becomes possible to flexibly cope with the improvement and expansion of the system.

[Brief description of drawings]

FIG. 1 is a block diagram showing an embodiment of a system event processing mechanism of the present invention.

FIG. 2 is a flowchart of a registration operation according to the present invention.

FIG. 3 is a block diagram of a comparative example.

[Explanation of symbols]

 1 Interrupt dispatch table 2 Hardware device interrupt 3 Software interrupt 4 Device driver 5 Event handler

Claims (1)

[Claims] 1. An interrupt dispatch table that accepts both a hardware device interrupt and a software interrupt, and an interrupt dispatch table that is activated when the hardware device interrupt is accepted by the interrupt dispatch table so as to correspond to the corresponding hardware. A prepared device driver, and an event handler having a configuration similar to that of the device driver, which is activated when the software device interrupt is accepted in the interrupt dispatch table and prepared so as to correspond to the corresponding software. A system event processing mechanism comprising: