JP2001005766A - Nonstop extensible driver - Google Patents

Abstract

PROBLEM TO BE SOLVED: To add a new function without stopping a computer to replace a driver. SOLUTION: This driver 2 which controls the operation of each different function of a hardware device under the control of an OS is provided with a function adding means 108 for user mode-side emulator which sends the source of a new function task described by a user to a driver side as a function addition instruction code for an emulator, a driver-side emulator table 110 which tables a detailed subdivision instruction group performed by the driver in the unit of each subdivision instruction and a driver-side emulating means 109 which refers to the table 110 and executes a received instruction code when the instruction code from the function adding means for an emulator is received via an OS 3.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an apparatus for dynamically adding a new function to a driver constituting an operating system of a computer, not as a compiled binary but as a source code.

[0002]

2. Description of the Related Art In a conventional method of adding a function to a driver in an operating system, when a new function is dynamically added, a program of the new function is compiled and sent to the driver. It must be converted to some form of code data. FIG. 18 shows, for example, “Dynamic management method and dynamic management method of driver function” disclosed in Japanese Patent Application No. 10-49754, in which a new function can be added to or deleted from a driver that is already running. And In the figure, reference numeral 3 denotes an operating system, 2 denotes a driver incorporated in the operating system, and 107 denotes a group of functions of the driver.
Function 107C), 101 is a new function source to be newly added to the driver, 102 is a means for compiling a new function source, 103 is a compiled new function, 104
Is an information acquiring unit, 105 is a new function adding unit, 106 is a command receiving unit, 301 is function list information, 302 is a map file, and 303 is an information editing unit.

FIG. 19 shows an operating system (O
S) is a flowchart showing an operation when a new function is added to the function group 107 incorporated in the driver 2 constituting a part of 3). The following describes a conventional dynamic addition method. A description will be given with reference to FIGS. For example, in FIG. 19, when adding a new function to the driver 2, first, the information acquisition unit 104 requests information from the instruction reception unit 106 (step 2001). This allows the current driver 2
The information of the function group 107 provided in the inside, that is, the function list information 301 is obtained (step 2002). Next, the source code 101 of the new function is created with reference to the information (step 2003). Next, compile means 1
02 to compile the new function source to create 103 compiled new functions (step 200).
4). Next, the address in the compiled new function is corrected (step 2005). Next, the new function adding means 10
5 and incorporated into the driver (step 200).
6).

[0004] Naturally, since this new driver incorporates new functions therein, the operating system must be installed after the incorporation.
When a new function is called from 3, the function can be executed. However, it is necessary to stop the computer for the replacement of the driver and perform the replacement work. Finally, the function list information 301 is updated. Thus, it is easy to add a task. As described above, in the conventional example, as shown in step 2004, if the source of a new function to be newly added is processed by a compiler, for example, if the source is created in C language, the source is created. It is necessary to convert the source into a binary file in an executable format by a C compiler such as, for example, Visual C ++. In a situation where the development environment has not been prepared, that is, when there is no compiler, a new It is not easy to add or modify functions.

[0005]

The conventional method for adding a dynamic task requires a compiling means for converting a program of a function to be newly added into an executable code form executable from a source created by a user. Although it is good when the development environment is in place, it is difficult for the customer where the product is delivered to have such a compilation means in general, and it is difficult to add or change the functions on site. Even with the conventional method, it is possible to create some newly added programs in a compiled state in advance and bring them, but it is not possible to respond flexibly by changing the program on the spot There were challenges. In the first place, there was a problem that it was necessary to stop the computer and work in order to replace the new driver compiled with the old version.

SUMMARY OF THE INVENTION The present invention has been made to solve the above problems, and without using a compiler,
It is an object of the present invention to enable a function to be dynamically added or modified to a driver.

[0007]

A non-stop extended driver device according to the present invention is a driver for controlling the operation of each function of a hardware device under the control of an operating system (OS). The user mode side emulator function addition means, which sends the source of the new function task to the driver as an emulator function addition instruction code, and the driver side, which lists the detailed subdivision instructions performed by the driver for each subdivision instruction unit An emulator table and driver-side emulation means for receiving the instruction code from the emulator function adding means via the OS and executing the received instruction code with reference to the emulator table are provided.

Further, the driver-side emulation means has a memory for collectively storing a source as an instruction code string, and reads a source from the user-mode-side emulator function addition means to read an instruction execution position. The instructions are executed sequentially according to

Further, the driver-side emulator table contains instruction codes in a plurality of languages in the table, and the driver-side emulation means executes an instruction code sequence corresponding to the language used by the user.

Further, the driver-side emulation means records the CPU occupancy record, and when the occupancy exceeds a predetermined occupancy range, the command execution is stopped and the operation is returned to the OS.

Further, the driver emulation means stores the source as a plurality of instruction code strings in the corresponding memory area, and reads the source from the user mode emulator function addition means into the corresponding area. The instructions are sequentially executed in the order indicating the instruction execution positions of these areas.

Still further, the driver-side emulation means records the number of executions of the new function task, and when the number of executions exceeds a predetermined number of executions, stops the instruction execution and returns to the OS. The non-stop extended driver device according to claim 1, wherein

[0013]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiment 1 The configuration and operation of a device that adds a new function to a driver without using a compiler will be described. FIG. 1 is a configuration diagram of a non-stop driver extension device according to the present embodiment. In the figure, 3 is an operating system (OS), 2 is a driver incorporated in the OS, and 107 is a group of functions of the driver, for example, function A 107A, function B 107
B, function C 107C. These are common elements that other devices have.

The user mode has the following elements.
Reference numeral 101 denotes a program source describing a function when a user wants to add a new function to the driver.
It is provided as a file on S. Reference numeral 104 denotes an information obtaining means, which is an application program for obtaining information on the functions A to C in the current driver. For example, issue an I / O control command to the driver,
Instruction receiving means 1 on the driver side (kernel mode side)
06 to obtain information. Reference numeral 302 denotes a map file, which is a file in which information on functions in the driver indicated by the function name and the address obtained by the information acquisition unit 104 is expanded. That is, the function information in the driver, which the user cannot know directly, is displayed in a visible manner. In other words, the contents of the function list information 301 on the driver side are developed so as to be seen by the user. Reference numeral 303 denotes an information editing unit that accesses the function list information 301 on the driver side (kernel mode side) and operates a flag to perform fine control. Reference numeral 105 denotes a new function adding unit, which is an application program for adding a new function to the current driver. For example, an I / O control command is issued and a new function is passed to the command receiving means 106.

On the other hand, the driver side (kernel mode side) has the following elements. Reference numeral 106 denotes a command receiving means for receiving a new function command code string from the user mode side. Specifically, when the I / O control instruction has an argument and a pointer to a variable area, the function list information 3
01 is copied to a specified variable area and the function information is passed to the user mode side, or in the case of a different instruction with a similar instruction, a memory area is secured in the driver and represented by the instruction. Copy the new function and add function list information 30
1 is updated. Reference numeral 301 denotes a function list, which is a file that summarizes the function group information in the current driver and indicates each function (function) name and an address in the driver. Every time a driver function is added or deleted, its contents change.

The new elements in the present embodiment are as follows. That is, on the user mode side, reference numeral 108 denotes an emulator function adding unit, and the user inputs a new function source 1
01 is sent directly to the instruction receiving means 106 on the driver side via the new function adding means 105 without compiling. On the driver side, reference numeral 109 denotes emulation means, which is a part of the I / O control routine, and executes an instruction code sent from the emulator function addition means. Reference numeral 110 denotes an emulator table, as shown in FIG. 2, which is composed of the names and addresses of micro detailed instructions. That is, FIG. 2A shows a part of the source of a program created by the user, FIGS. 2B and 2C show examples of the emulator table 110, and the header section 200 in FIG. Name 20 and address 20 where its instruction string is stored
2 is written, and the body part 210 in FIG. 2C shows a state where the detailed instruction code 211 at the address is described in an executable format.

The operation of the apparatus including these new elements, ie, the emulator function adding means 108, the emulating means 109, and the emulator table 110 will be described. Emulator table 1 to install new features
You need to know 10 pieces of information. This emulator table is obtained as follows. FIG. 3 is an operation flow showing a procedure for installing an instruction code and its address in the emulator table. This is out of the range of the operation by the emulation means described in the present embodiment. First, the initial setting operation of the emulator table will be described. The emulator table is created for each detailed instruction corresponding to the new function source. In step 9801, a function (function) including an instruction code sequence is created for the body section 210. In step 9802, an instruction name and an address are created for the header section 200. In the present embodiment, there is no compiling means within the scope of the present invention, and the new function adding means 105 and the emulator function adding means 108 convert the instruction code sequence shown in FIG. , Step 980
In step 3, the data is stored in the data area in the driver.

FIG. 4 is a diagram showing an operation flow of a driver incorporating a new function, for example, including elements on the user mode side. Here, the addition of the ADD detailed instruction enclosed by the ellipse in FIG. 2A will be described. This is ABC
Is a process of adding 1 to the variable, and a function named ADD is used. When a user adds a new function to a currently running driver, it is necessary to grasp the status of the currently running driver, such as what variables are being used. Then, in order to grasp the function information currently supported by the driver, a system call instruction is issued to the driver via the information acquisition means 104 (step 9701). As the system call instruction in this case, for example, an I / O control instruction having an argument ARG1 for addressing the function list information list of the driver may be used. Command receiving means 10 receiving the above I / O control command
6 is a function list information 30 incorporated in the driver.
1 is retrieved, and the information of the incorporated function / variable is obtained and returned to the information obtaining means 104 (step 9702).

The user creates a source code including a new function by referring to this information (step 970).
3). However, only the instructions included in the emulator table can be used. For example, an instruction code string that can call a function already incorporated in the driver or access a variable already incorporated (substantially, for example) Function) can be prepared. When it is desired to handle a function / variable already incorporated in a program created by the user, the value obtained from the function list information 301 may be used as it is. The operation so far is the same as the "dynamic management method and dynamic management method of driver function" described in [Prior Art]. Next, one line of the program is sent to the driver using the emulator function adding means 108 (step 9704). At this time, the emulator function adding unit 108 performs a transfer operation to the instruction receiving unit 106 by an I / O control instruction. For example, a method of passing the program as one of the arguments at the time of issuing the I / O control instruction is considered. In the case of the example of “ADD” in FIG. 2A, “ADD ABC1” is sent. That is, AB
This is a process of adding 1 to a variable C. Command receiving means 10
Reference numeral 6 secures an area corresponding to the size of the one-line program in the driver area, and executes the program. One emulator function adding unit 108 waits for a return from the driver.

Next, the emulation means 109 receives this one-line program, compares it with the header section 200 of the emulator table, and if there is an instruction that matches the instruction contained in one line, the address of the corresponding instruction, that is, The body of the emulator table is called (step 9705). In this example, the ADD of 201 matches the instruction, and the code of the address of “0X80001100” of 202 is called. The code at this address is a function for performing addition, and processing for adding argument 1 is performed. As a method of extracting the character string of the instruction from one line,
For example, as the language format of this program,
Assuming that the command, argument 1, argument 2, and the following grammar are used, it is possible to specify a character string indicating the command by inserting a space between each of the command and argument. Further, the argument can be passed as it is when calling the body part of the corresponding emulator table. If there is no corresponding instruction in the emulator table, the processing ends without doing anything. After the execution of the instruction, if there is a return value, the return value is returned to the emulator function adding means 108 which has called the return value. If the processing is abnormal, a return value indicating them is also returned.

Next, emulator function adding means 108
First checks the return value, if any, and uses it if it should be used in a new program. If a return value indicating that the previous process is abnormal is returned, it is conceivable to stop the subsequent processes or take a measure for asking the user what to do. Check if there are any new programs,
If there is, return to step 9704 (step 970)
6). When there is no new program, the processing of the emulator function adding means ends. As described above, the command receiving means 106 and the emulation means 109 as a part of the I / O control routine are incorporated in the driver side, and further detailed instructions are managed and displayed in the emulator table, and are displayed on the user mode side. The new function code added to the new function source 101 by the function adding means 105 and the emulator function adding means 108 is sent and executed. Thereafter, in order for the user to specify reuse of the new function, the previously executed information remains because the information remains in the function list information 301 due to the above-described installation. You can specify this as an argument. Therefore, according to the present embodiment, new functions can be added without stopping the driver running on the operating system and without using a new development environment.

Embodiment 2 FIG. Next, another embodiment of the present invention will be described with reference to FIGS. In this embodiment, the buffer prepared for one line is dynamically provided in the emulator table or the emulation means.
Instead of sending the new program line by line to the driver and executing it, it is sent in batches. FIG. 5 shows the configuration of the emulator table in the present embodiment. Compared to the first embodiment, a buffer indicated by component 220 and an execution pointer indicated by component 230 are newly added. I have. The execution pointer 230 indicates at which position the program is currently being executed.

Next, a method of adding a new function source will be described with reference to the flowchart of FIG. 6, focusing on differences from the first embodiment. First, in steps 9601 to 9603 until a new function is created, the same processing as steps 9701 to 9703 in FIG. 4 showing the case of the first embodiment is performed. After that, in the first embodiment, the emulator function adding unit 108 sends the program line by line, whereas in the present embodiment, the program is sent collectively. (Step 9604). It is possible to use both the present embodiment and the first embodiment in the same system. In order to perform proper use, for example, when data is sent to the driver using an I / O control instruction, a new argument is provided, and the value of the argument is used to inform the emulation means of which one is used. . On the emulation means side, it is only necessary to refer to this argument and branch to which processing should be performed.

The instruction receiving means 106 that has received the new program determines that emulator processing is required based on the argument, and shifts the processing to the emulator means 109. The emulator 109 substitutes the contents into the buffer area 220 in the emulator table 110 (step 9604). At this time, a value indicating the head position of the buffer is assigned to the execution pointer 230 indicating the position where the execution is being performed. As a method of inputting data to the buffer, for example, a method of directly inputting a character string may be used. In such a case, a value indicating the number of the line from the head of the buffer of the execution pointer is appropriate. Of course, the physical address value may be substituted for the execution pointer. Next, the emulation means 109 checks whether or not there is a program that still needs to be processed in the buffer 220 (step 9607). At this time, as a method of checking whether or not the program remains, for example, a method of using an execution counter can be cited. To explain using the above example, when a line number is used for the execution counter, a method is conceivable in which the total number of lines read into the buffer is recorded in the data area in advance and compared with this. Further, even when a physical address is used for the execution counter, a method of recording the total amount read into the buffer in the same manner and comparing the total amount can be considered. If there is still a program in the buffer, the processing from step 9605 is repeated, and if not, the processing is terminated. When ending the program, the buffer 220 and the execution counter 23
0 is released (step 9608).

In the second embodiment, a newly created program is read at a time.
Next, a case where it is desired to use the once created and executed program again and repeatedly will be described. New Function Source 10
The new function of the driver added to 1 is sent to the instruction receiving means and executed by the emulation means while looking at the emulator table. The driver registers this program in the new function list information as a new function. In this way, the user can easily understand the new function from the map file and can use it directly. FIG. 7 is a block diagram corresponding to FIG.
FIG. 7 is an operation flowchart corresponding to FIG. That is, the contents executed by the newly created new function source executed by the emulation means 109 are newly created in the function group 107. 7 are the same as those in FIG. 1 and FIG. 5, and only the emulation result conversion means 111 of the component is newly added.

Next, the procedure for adding the executed new function source to the function group will be described with reference to the flowchart of FIG. Here, a case will be described in which the function C indicated by 107C in FIG. 7 is initially not in the function group, and a newly created new function is added as this function C. First, steps 9501 to 9507 until a new function is created and executed repeatedly.
Performs the same processing as Steps 9601 to 9607 in FIG. After all the processes are completed, the emulation result conversion unit 111 converts the executed program in the buffer into executable code, and executes the function C (107).
C) is assigned to the function group (step 9508). Next, the function list information 301 is updated (step 950).
9) Finally, the buffer / execution counter is released (step 9510).

Although the coding is performed to insert the executed new function program into the function group, the following measures can be considered. The emulation means 109 executes the new function program one line at a time in step 9506. This is, as already described in the first embodiment, actually analyzing the statement in one line and executing the command. Is called repeatedly with an argument in some cases. At this time, if the actually executed subroutine call is recorded in the memory, the code of the new function program is completed when all the programs have been executed. All that is required is to put this content into the function group. As described above, by providing the emulation result changing unit 111 and collecting it in the function list information, it is possible to add a newly created and executed program as a new function to the function group. Also, as in the first embodiment, new functions can be added without stopping the driver being executed.

Embodiment 3 In the above-described embodiment, a case has been described in which a function is added by using a driver already existing in the emulator table as a detailed instruction. In the present embodiment, a new detailed instruction not yet in the emulator table is added to the emulator table. The case where a new function using these functions is added will be described. Hereinafter, the present embodiment will be described with reference to FIGS. FIG. 9 is a configuration diagram of an apparatus according to the present embodiment.
The emulation table changing means 112 is newly provided in the configuration of FIG. FIG. 10 shows the 110b emulator table in the present embodiment. Here, in order to explain the operation when adding a new instruction Z, the header 200 and the body 210 are related to the instruction Z. New components 201Z and 202
Z and 211Z are added.

Next, a procedure for adding a new instruction to the emulator table will be described with reference to the flowchart of FIG. For example, as described in the above embodiment, if an emulator table is used in which a header section contains a character string of an instruction and its address, first, a function for a new instruction is created. Compile (step 9401). Next, the compiled object code and the name of the new instruction are passed to the driver. When sending to the driver side,
Similarly to the "dynamic management method and dynamic management method of driver function" described in [Prior Art], the driver is sent to the driver using the new function adding means 105 and the instruction receiving means 106 in FIG. Pass the contents to the table change means. To perform this operation, for example, the new function adding unit 10
5 when using the system call command, the command receiving means 10
In this case, a value indicating that this call is to be added to the emulator table is provided in the first argument, and data to be newly added is provided in the second argument. The name and object code of
It can be passed to the emulator table conversion means 112 (step 9402).

Next, this emulator table conversion means 1
In 12, new information is added to the emulator table. For example, to add instruction Z, first
The code 211Z of the instruction Z is assigned to the body part. If there are other variables and functions referenced in this instruction,
The address is determined with reference to the function list information 301. Next, in the header part, the name of the instruction Z is set to 201Z,
Then, the position of the body part, that is, the address value substituted earlier, that is, the address value is substituted into the address 202Z where the code of the instruction Z is present. (Step 9403). In this way, by adding the emulator table changing means, it becomes possible to add a new instruction to the emulator table being used.

Embodiment 4 FIG. Next, the device of the present embodiment will be described with reference to FIG. In the present embodiment, a case will be described in which not only one emulator table but also a plurality of emulator tables are provided, and the emulator table can support not only one type of programming language but also a plurality of programming languages. FIG. 12 is a configuration diagram showing a difference between emulator tables in the present embodiment. In this example, three types of languages, D, E,
F, emulator tables 110D and 110 corresponding to
E, 110F are provided.

The method of adding a new function source is basically the same as in the case of a single emulator table. However, it is necessary to associate and recognize which language the instruction code from the new function source 101 corresponds to. In order to recognize which language is supported, data is passed to the instruction accepting means 106 by a system call instruction when using the new emulator adding means 108. 108
Issues an I / O control instruction,
You can specify which language this call corresponds to, that is, which emulator table you need to access. As a method of recognizing the address of each table, pointers to the respective tables may be combined into a single table, and the table may be searched first. In this way, by preparing a plurality of languages corresponding to the number of languages using the emulator table, it is possible to newly create and execute a program corresponding to a plurality of languages.

Embodiment 5 FIG. Here, when a plurality of processes are executed, the CPU is controlled so as not to occupy the CPU.
A method will be described in which a flag including a numerical value indicating the degree of use of U is newly prepared, and distribution is performed using the flag. In this way, it is possible to prevent a program executed at a high priority of the driver level from delaying Windows processing. An apparatus according to the present embodiment will be described with reference to FIGS. In the present embodiment, a buffer 22 is provided for each emulator table corresponding to each language.
0 has a variable indicating how much the CPU may be occupied when executing the program, and a variable indicating how much the CPU is currently used (occupied). Is monitored so as not to disturb the operation. FIG. 13 shows the configuration of the emulator table 220 for each language in the present embodiment. The configuration of the emulator table 220 differs from that of FIG. 5 described in the previous embodiment.
The CPU occupancy indicated by 0 and the CPU usage indicated by the component 250 are added.

Next, a CPU distribution method utilizing the CPU occupancy and the CPU usage will be described. (1) First, CPU occupancy 240 and CPU usage 250
Will be described. The processing required for the initialization is simply to assign a desired numerical value to each, but it must be performed before executing the program itself as a condition. For example, when creating the new function source 101, a method is conceivable in which the numerical value of the CPU occupancy is always written in the first line of the program and the information is passed to the emulator table. Also, emphasis is placed on making it easy to change, and the CPU occupancy is not written in the new function source, and the emulator function adding unit 108 uses this CPU as an argument when issuing an I / O control instruction.
It is also conceivable to add the occupancy and pass it to the command receiving means 106.

(2) Next, using both variables,
The procedure of actually distributing the CPU will be described with reference to FIG. First, the work required to execute a new function in the source for the currently executing driver is shown in the flowchart of FIG. Basically, it is the same as the flowchart of FIG. 6 used in the description of the second embodiment, except that the CPU usage rate is written and exceeds the occupancy rate before repeatedly executing the program. Is to make sure they are not there.

Next, using the flowchart of FIG.
The work required to execute a new function on the source in consideration of the U occupancy will be described focusing on differences from the second embodiment. First, steps 9301 to 9306 from creation of a new function to execution of the first line are the same as steps 9601 to 9606 in FIG. After the execution of one line, a numerical value indicating how much the CPU is occupied by the execution of this line is substituted into the CPU utilization (step 9).
320). For example, the time before execution and the time after execution may be measured and the difference may be used, or a timer may be set and the difference between before and after execution may be substituted. Next, it is checked in step 9307 whether or not there is a program. If there is, a comparison is made with the CPU occupancy (step 9321). This means, for example, that the base time is 1
If you set 0 milliseconds and set this to 10%,
From the numerical value of the CPU usage rate substituted in the previous step 9320, a method of determining what percentage has been used can be considered.

If the CPU occupancy is not exceeded,
Repeat from step 9305. On the contrary, if it exceeds, the CPU usage rate is reset (step 9322),
After SLEEP, the CPU surrenders to another process (step 9323). For example, a method of SLEEPing a task performing its own process for a certain period of time can be considered. Complete the entire program, NO at step 9307
After that, the buffer / execution counter is released and all the processing is completed as in the second embodiment (step 9308). As described above, in the emulator table, the CPU usage rate indicating the percentage of CPU usage and the CPU usage amount indicating how much the program can use the CPU.
By using the occupancy, it is possible to prevent a situation where the CPU is occupied and other applications and the OS cannot be executed when a new function is additionally executed in the driver.
In addition, since the usage rate can be specified, it is possible to allocate the CPU according to the processing to be executed.

Embodiment 6 FIG. In the above embodiment, the degree of occupation of the CPU is limited for the entire processing of the functions in the driver. On the other hand, here, there are a plurality of processings inside the driver, and each processing is individually performed by the CPU. The purpose is to set the occupancy. Next, an apparatus according to the present embodiment will be described with reference to FIG. In this embodiment, a plurality of newly created programs are simultaneously executed for each emulator table by providing a buffer, a CPU occupancy rate, and a CPU usage rate for each emulator table corresponding to each language. Let it. FIG.
FIG. 5 is a diagram showing a configuration of an emulator table according to the present embodiment. Here, it is assumed that the setting situation is such that three types of tasks can be executed simultaneously. For this reason, newly renumbered components have been added. The assumed plurality of task names are task G, task H, and task I, each of which has a buffer (220G to 220G).
220I), execution pointers (230G to 230I), C
PU occupancy (240G-240I), CPU usage (2
50G to 250I).

The operation of this embodiment having a plurality of buffers is the same as that of the previous embodiment having only one buffer. However, it is necessary to distinguish which task is to be executed.
When an I / O control instruction is issued when the instruction receiving means 106 is called, an argument is added.
What task (in this example, G, H or I, for example, numerical values 0, 1, and 2) may be specified. As mentioned above,
As in the present embodiment, a buffer for reading a newly created program at a time in the emulator table, an execution pointer indicating how far the program has been executed, a CPU
A plurality of tasks can be executed by aligning the variables that determine the occupation ratio of the task, and the variables indicating how much CPU has been used so far, by the number of tasks that have been executed at the same time.

Embodiment 7 A driver extension device that can execute the same processing a plurality of times once a new function is added will be described. Usually, once you send a new function to the source and have it executed, you have to send the source again or send a command to execute the new function stored in the function group to execute it again. However, this function allows you to specify how many times the program should be repeated once the source has been sent. Next, the device of the present embodiment will be described. In the present embodiment, a task executed in the emulator table is provided with a counter for the number of executions, so that the task can be executed not only once but also a plurality of times. FIG.
FIG. 3 is a diagram showing a configuration of an emulator table according to the present embodiment. Here, it is assumed that the setting situation is such that three types of tasks can be executed simultaneously. It is assumed that task G, task H, and task I are assumed, and the number of repetitions (260 G to 2
60I).

The operation of this embodiment will be described with reference to the flowchart of FIG. Steps 9201 to 92 in the figure
08 is the same as steps 9601 to 9608 in FIG. 6, and steps 9220, 9221, and 9222 are newly added in this flowchart. Here, the task G will be described as an example. First, steps 9201 to 9204 for sending a newly created program to the driver are the same as above. Next, a value is substituted for the number of repetitions 260G. As for the method of passing this value, the value may be passed as a new argument when an I / O control command is issued when the command receiving means 106 is called from the emulator function adding means 108. Steps 9205 to 9207 for executing the program are the same as above. When the execution of the program is completed, the value of the repeat counter is checked. If the value is not 0, various variables are initialized (step 9222), and the process is repeated. Initialization of various variables includes initialization of an execution pointer and decrementing of a repeat counter. Repeat counter is 0
, The buffer and the execution counter are released, and the process is completed (step 9208). As described above, by setting variables indicating how many times to execute a newly created program in the emulator table as in the present embodiment, it is possible to easily set a task that must be executed multiple times.・ It can be executed.

[0042]

As described above, according to the present invention, an emulator function adding means, an emulator table, and an emulating means are provided. When an instruction code for adding a new function is received for a driver, a subroutine format is provided. The driver operates, so that a compiling means (compiler) is not required, and there is an effect that the scale is small and a new function can be added without stopping the computer.

Since the emulator table which can refer to the instruction codes corresponding to a plurality of languages is provided, the effect of reducing the restrictions on the language used by the user is added.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of a non-stop extended driver device according to Embodiment 1 of the present invention.

FIG. 2 is a diagram illustrating an example of an emulator table and an example of a new function source.

FIG. 3 is an operation flowchart showing an installation procedure according to the first embodiment.

FIG. 4 is an operation flowchart of a driver according to the first embodiment;

FIG. 5 is a diagram showing an example of an emulator table according to the second embodiment of the present invention.

FIG. 6 is an operation flowchart of a driver according to the second embodiment.

FIG. 7 is a configuration diagram of another non-stop extended driver device according to the second embodiment.

FIG. 8 is an operation flowchart of another driver according to the second embodiment.

FIG. 9 is a configuration diagram of a nonstop extended driver device according to a third embodiment of the present invention.

FIG. 10 is a diagram showing an example of an emulator table according to the third embodiment.

FIG. 11 is an operation flowchart of a driver according to the third embodiment.

FIG. 12 is a diagram showing an example of an emulator table according to Embodiment 4 of the present invention.

FIG. 13 is a diagram illustrating an example of an emulator table according to the fifth embodiment of the present invention.

FIG. 14 is an operation flowchart of a driver according to the fifth embodiment.

FIG. 15 is a diagram illustrating an example of an emulator table according to the sixth embodiment of the present invention.

FIG. 16 is a diagram illustrating an example of an emulator table according to the seventh embodiment of the present invention.

FIG. 17 is an operation flowchart of a driver according to the seventh embodiment.

FIG. 18 is a configuration diagram of a function addition management method for a driver as a reference device.

FIG. 19 is an operation flowchart of a function addition management method for a driver as a reference device.

[Explanation of symbols]

101 new function source code list, 104 information obtaining means, 105 new function adding means, 106 instruction receiving means, 107 driver, 107A, 107B, 107C
Driver function A, function B, function C, 108 emulator function addition means, 109 emulation means, 11
0, 110B, 110D, 110E, 110F emulator table, 111 emulation result conversion means,
112 emulator table changing means, 200 emulator table header, 201, 201Z instruction name, 202, 202Z instruction address, 210 body, 211, 211Z detailed instruction code, 220 driver buffer area, 230 execution pointer, 240C
PU occupancy, 250 CPU usage, 301 function list information table, 302 map file, 303 information editing means.

Claims (6)

[Claims] 1. A driver for controlling the operation of each function of a hardware device under the control of an operating system (OS), wherein a source of a new function task described by a user is described as an emulator function addition instruction code. Send to the driver side,
User mode side emulator function addition means, driver side emulator table in which a detailed subdivision instruction group to be performed by the driver is tabulated for each subdivision instruction, and an instruction code from the emulator function addition section is stored in O
A non-stop extended driver device comprising: driver-side emulation means for executing an instruction code received by referring to the emulator table when received via S. 2. The driver-side emulation means has a memory for collectively storing a source as an instruction code string, and reads a source from the user-mode-side emulator function addition means, and reads the source in accordance with an order indicating an instruction execution position. 2. The non-stop extended driver device according to claim 1, wherein instructions are sequentially executed. 3. The driver-side emulator table stores instruction codes in a plurality of languages in a table, and the driver-side emulation means executes an instruction code sequence corresponding to a language used by a user. The non-stop extended driver device according to claim 1, wherein 4. The driver-side emulation means includes a CPU
2. The non-stop extended driver device according to claim 1, wherein the occupancy record is recorded, and when the occupancy exceeds a predetermined occupancy range, the instruction execution is stopped and the operation is returned to the OS. 5. The driver-side emulation means stores a plurality of source codes as a sequence of instruction codes in a corresponding memory area, and reads the source from the user mode-side emulator function addition means into the corresponding area. 3. The non-stop extended driver device according to claim 2, wherein instructions are sequentially executed according to an order indicating an instruction execution position of each area. 6. The driver-side emulation means records the number of executions of a new function task, and when the number of executions exceeds a predetermined number of executions, stops the instruction execution and returns the operation to the OS. The non-stop extended driver device according to claim 1.