JPH0458351A - General-purpose device driver - Google Patents

Abstract

PURPOSE:To easily obtain a device driver by defining a part of a decentralized control processor that is not dependent on its type as an independent part in terms of the standard processing and building the proper processing into the control processor as a built-in subroutine. CONSTITUTION:A part of a decentralized processor 3 that is not dependent on its type is defined as an independent part in terms of the standard processing, and the proper processing is built into the processor 3 as the subroutines 5a - 8a. That is, the standard processing independent of the processor 3 is carried out and then a fact whether the routines 5a - 8a are registered or not. If so, a proper processing routine is called out. If not, the next processing is carried out. Thus a device driver is easily produced to the processor 3 of a different type.

Description

DETAILED DESCRIPTION OF THE INVENTION [Object of the Invention] (Industrial Application Field) The present invention relates to a general-purpose device driver that drives a distributed control processor attached to a computer.

(Prior Art) FIG. 3 shows the structure of a device driver that drives a conventional distributed control processor, and FIG. 4 shows the relationship between the distributed control processor and an application. 10 is O5 (operating system), 16 is distributed control processor (
device), 17 is an application.

Here, 1. The initialization processing unit 11 makes the data resident in the memory, secures a work buffer, and initializes the hardware. The hardware request processing section 12 accepts requests from the application 17 and checks their validity. The hardware request processing unit 13 makes a request to hardware (start l10). The interrupt acceptance processing unit 14 accepts a completion notification for the above request. The completion processing unit 15
Generates a status and notifies the application 17 of completion. This device driver is prepared for each distributed control processor.

(Problems to be Solved by the Invention) Conventionally, since the processing contents differ for each distributed control processor that is a device, when the distributed control processor changes, the entire O8 needs to be changed accordingly.
There was a problem in that a device driver had to be created for each type of distributed control processor, which required a lot of man-hours for development.

The present invention was made in order to eliminate such conventional drawbacks, and it is possible to
The purpose is to provide a general-purpose device driver that can be easily developed and created.

[Structure of the Invention] (Means for Solving the Problems) A general-purpose device driver of the present invention that achieves the above-mentioned conventional object includes a device driver that drives a distributed control processor that includes a part that does not depend on the type of the distributed control processor. It is characterized by incorporating as a subroutine a unique process that is made independent as a standard process and does not depend on the type of distributed control processor.

(Operation) In the present invention, first, standard processing that does not depend on the distributed control processor is executed, and after the execution of the standard processing is completed, it is checked whether a built-in subroutine has been registered. If it is registered, its specific processing routine is called. If it is not registered, the process moves to the next step. Device drivers can be easily created for different types of distributed control processors.

(Example) Hereinafter, an example of the present invention will be described in detail with reference to the drawings.

FIG. 1 is a block diagram showing the configuration of a general-purpose device driver according to an embodiment of the present invention.

In the figure, 1 is an application that initializes devices and makes requests to drivers, 2 is an O5 (operating system), and 3 is a distributed control processor (device) such as a disk controller 2 and a communication controller. The device driver of this embodiment includes an initialization processing section 4 that makes the device resident in memory, secures a work buffer, and initializes the hardware, and a hardware request processing section 5 that receives requests from the application 1 and checks validity. , a hardware request processing unit 6 that makes a request to hardware (start 110), an interrupt reception processing unit 7 that accepts a completion notification for the above request, and a status generation and completion notification to the application 1. Completion processing unit 8
Equipped with

Furthermore, regarding the request reception processing section 5, hardware request processing section 6, interrupt reception processing section 7, and completion processing section 8 of the device driver of this embodiment, the parts that do not depend on the type of distributed control processor 3 are set as standard processing. Processes unique to the distributed control processor 3 are incorporated as built-in subroutines 5a, 6a, 7a, and 8a. In addition, subroutine 5 executes specific processing required in each processing unit.
It has a specific processing routine vector table 9 that stores addresses of g, 6a, 7a, and 8a.

Next, the processing of the device driver will be explained with reference to the flowchart shown in FIG.

As an example, the case of request reception processing will be explained. First, standard processing that does not depend on the distributed control processor 3 is executed (step Sl). After the standard processing has been executed, the specific processing routine vector table 9 is referred to to check whether any built-in subroutines are registered (step S2). If it is registered, call its specific processing routine (
Step S3). If it is not registered, the process moves to the next process (hardware request process).

As described above, parts that do not depend on the type of distributed control processor 3 are made independent as standard processes, and processes specific to the distributed control processor 3 are incorporated into subroutines 5a, 6a, and 7a.
, 8a, it is possible to easily create device drivers for different types of distributed control processors.

[Effects of the Invention] As explained above, according to the general-purpose device driver of the present invention, parts that do not depend on the type of distributed control processor are made independent as standard processing, and processing specific to the distributed control processor is incorporated as a built-in subroutine. Therefore, the number of man-hours required to develop a device driver, which has conventionally been created every time a distributed control processor is developed, can be drastically reduced.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing the configuration of a general-purpose device driver according to an embodiment of the present invention, FIG. 2 is a flowchart explaining processing operations by the general-purpose device driver of this embodiment, and FIG. 3 is a block diagram of a conventional device driver. FIG. 4 is a block diagram showing the mutual structure of the device driver, application, and distributed control processor. DESCRIPTION OF SYMBOLS 1...Application, 2...0813...Distributed control processor, 4...Initialization processing unit, 5
. . . request reception processing unit, 6 . . . hardware request processing unit, 7 . . . interrupt reception processing unit, 8 . . . completion processing unit.
9... Specific processing routine vector table, 5a, 6a
, 7a, 8a... built-in subroutines. Applicant: Toshiba Corporation

Claims (1)

[Scope of Claims] In a device driver that drives a distributed control processor, a part that does not depend on the type of distributed control processor is made independent as a standard process, and a specific process that does not depend on the type of distributed control processor is incorporated as a subroutine. A general-purpose device driver featuring: