JPS63113739A - Overlay system for os - Google Patents

Abstract

PURPOSE:To actuate an OS in a small executing area with use of a normal disk driver in a comparatively small-scale computer system containing no dynamic address conversion mechanism DAT, by acquiring a loadable area and starting it when an input/output request is detected against an unloaded driver. CONSTITUTION:When an input/output request is given to an unloaded driver, a driver control part 3 stores a processing request in an FIFO register 5. When a multiple interruption is eliminated, an overlay control pat 7 is started before the control is shifted to a scheduler. In an overlay control process a working area of the driver is controlled and the driver is loaded and unloaded. The register 5 is read after the control is shifted to the part 7 and a non-working drive is written to a disk as necessary to produce an idle area. Then said driver is loaded and then registered and started. An overlay is caused to the driver by making use of an idle time for input/output of the disk and therefore an OS can have its effective working in a small executing area.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to an OS overlay method suitable for a computer system that does not have a virtual memory control function (address translation function).

[Conventional technology]

In computer systems, methods for operating programs larger than the memory installed in the computer have been discussed in various texts 1 related to OS (operating system).

For example, it is described in Chapter 6 of Iwanami 1 Lecture, Information Technology-16, ``Function and Configuration of Operating System 11,'' which describes the methods and principles of swap, overlay, virtual memory, etc.

[Problem that the invention seeks to solve]

However, many of the above-mentioned memory utilization techniques mainly relate to the operation method of applications (tasks) larger than the memory, and do not discuss the operation area of the OS itself. It is easy to apply the conventional virtual memory method to the operation of the OS, but in this case, the dynamic address converter 4W (DAr)
Translator) is required.

The present invention uses an ordinary disk driver in a relatively small computer system not equipped with a DAT,
The objective is to operate S in a small execution area.

[Means for solving problems]

The above object is achieved by acquiring a loadable area and activating the driver when an input/output request to an unloaded driver, which is part of the OS, is detected. In the present invention, since loading is performed using a disk driver that is also used for other purposes, the processing request is stored as a system at the above timing, and the driver is loaded and started at a timing when the disk driver can be used. Let's do it.

[Effect]

When an input/output request is issued to an unloaded driver, the driver management unit stores the processing request in a FIFO (FIFO).
t I n First, 0ut) Store in register. When multiple interrupts are resolved, the overlay management section is activated before moving to the scheduler. Overlay management involves managing the driver's operating area and loading and unloading the driver. When control is transferred to the overlay management section, it reads the above FIFO register, writes out non-operating drivers to disk if necessary, creates free space, loads the driver, registers it as a driver,
Perform startup processing.

〔Example〕

Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 shows the overall configuration of software for realizing the present invention. In this system, the driver activation request is made through the input/output request 5VC2.
There are requests from (Application Program) (1) and direct activation requests from the input/output driver 4. The driver management section 3 includes a driver startup processing section and a driver termination processing section.

5 is a FIFO register for storing input/output processing requests issued to unloaded input/output drivers; 6 is a FIFO register for storing input/output processing requests issued to unloaded input/output drivers; This is a FIFO register for waiting an input/output request read from register 5. The overlay management unit 7 reads the input/output request from the register 5, loads the corresponding input/output driver from the disk 8, and activates it. When loading fails,
The input/output request is stored in the register 6.

Next, the flow of processing will be explained.

When a driver activation request is made, the driver management unit 3
Performs normal busy/ready processing and immediately before transferring control to driver 4, determines whether the corresponding driver is loaded or not, and if not loaded, stores information regarding the startup request in register 5 and processes. finish. It should be noted that loaded/unloaded is determined based on whether the driver address is registered or not, as will be described later in 5. When the process of the driver management unit is finished, it is determined whether the continuation is a multiple interrupt or not, and when the multiple interrupt is resolved, the overlay management unit 7
is started. The overlay management unit 7 reads the request content from the register 5 that stores the input/output request, searches for an empty area within the driver's operation area where the corresponding driver can be loaded, and loads the corresponding driver. If the search fails, the contents read from the register 5 are stored in the standby register 6. When the processing of the driver 4 is completed, a completion notification is sent to the driver management unit 3, and the driver management unit 3 performs termination processing such as sending an end event and restarting the task. at this point.

Since there is no need to keep the completed driver in memory, the input/output request stored in the standby register 6 is transferred to the input/output request register 5, and then the execution area is transferred to the overlay management unit 7. A search and loading process is attempted.

Next, the operation of the overlay management section will be explained with reference to FIGS. 2 and 3.

The area for overlaying is managed using a management table 21 having information as shown in FIG. 2 for each driver.

FIG. 3 is a flowchart 1- showing the control procedure of the overlay management unit 7. First, in step 31, it is determined whether there is a disk access for overlay. In this case, for example, if a flag at a specific address is turned ON when a disk access request is made and turned OFF when the request is completed, it is possible to know whether or not a disk access is being made by determining 0N10FF at that address. If there is a disk access, the process returns; if not, the process proceeds to the next step 32, reads the input/output request register 5, and determines which input/output driver the request was made to. As a result, the management table shown in FIG. 2 can be obtained. Next, a memory area is acquired according to the size of the driver defined in the above table 2 (step 33). If the acquisition is successful, the program is loaded from the disk based on the data in the management table (FIG. 2) (step 34), and the address is registered in the start address of the management table (step 35).

If the acquisition is not possible, read the management table corresponding to the other driver, and for those whose status is ready (no input/output request), write the program from the main memory to the disk according to the data in the management table. 36), Unregister by embedding "NULLJ" in the start address on the \I Riko table Step 37), release the area and perform the acquisition operation again. If possible, wait for the contents of the I/O request.
Register in the IFo register and complete the process.

Next, other embodiments of the present invention are shown in FIGS. 1 and 4.

This will be explained with reference to FIG.

In this embodiment, the overall flow of processing is the same as in the first embodiment. However, if the management table for each driver is expanded as shown in Figure 4, and the corresponding driver has to process at high speed, "○NJ.

At other times, control is performed so that ``○FFJ'' is achieved.

The flow of the overlay management section 7 is shown in FIG. The processing content is basically the same as that shown in Fig. 3, and the conditions for writing the driver to the disk include confirming that the status is ready and that the lock information is OFF (step 51). ).

In the above embodiment, two FIFOI registers are used to improve efficiency in the event of a load failure (area acquisition failure). However, if only one FIFOI register is used, the registration process to register 6 is 5, and do nothing in the driver termination process.

In addition, in the present invention, when the memory management method is set to a method that does not use the management area as management data, such as bin 1 ~ map management, after loading the driver, the driver that has not been destroyed may be re-registered as is. It is possible to respond quickly to primary input/output by using

〔Effect of the invention〕

According to the present invention, by overlaying drivers using free disk input/output time without virtualizing addresses, it is possible to efficiently operate an OS in a small execution area.

[Brief explanation of the drawing]

FIG. 1 is an overall configuration diagram of a system for implementing the present invention;
Fig. 2 is a diagram showing one embodiment of the driver management table, Fig. 3 is a processing flowchart of the overlay management section, Fig. 4 is a diagram showing another embodiment of the driver management table, and Fig. 5 is a diagram of the driver management section. It is a process flowchart which shows another Example. 3... Driver management unit, 5... FIFO I register for storing input/output requests, 6... FIFO register for storing standby input/output requests, 7... Overlay management unit, 8.
...A secondary storage device that stores drivers.

Claims (1)

[Claims] 1. In a computer system, an overlay management means for managing the operation area of an input/output driver and a secondary storage storing its code, and an FI for storing input/output requests.
It has an FO register, and when an input/output request occurs, it determines whether the corresponding input/output driver is already loaded or not, and if it is not loaded, it stores that fact in the FIFO register and finishes the processing related to the input/output. . An OS overlay system, characterized in that after multiple interrupts are resolved, the FIFO register is read in the management section, and the input/output driver is loaded and operated.