JPH11149385A - Multi-OS configuration method - Google Patents

Abstract

(57) [Summary] The present invention provides a system in which a plurality of OSs can be simultaneously run on a single computer easily with only software, in contrast to the OS control system having a complicated and large overhead of the conventional virtual computer system. I do. According to the present invention, a new function that operates completely independently of the first OS can be completely incorporated into a computer, thereby shortening an interrupt response time and improving reliability. Kind Code: A1 A procedure for dividing a hardware resource managed by a first OS and another OS, a procedure for starting another OS, a procedure for switching an execution OS, and an OS for performing an interrupt process depending on an interrupt factor are determined. The simultaneous execution of a plurality of OSs is realized by a procedure for activating an appropriate interrupt handler.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to a multi-OS for operating a plurality of operating systems on one computer.
Related to the configuration method.

[0002]

2. Description of the Related Art An ordinary computer operates one operating system, which manages computer resources such as a processor, a memory, and a secondary storage device of the computer, and sets a resource schedule so that the computer can operate efficiently. We are implementing. There are various types of operating systems. What is excellent in batch processing, TSS (TimeSharingS
ystem), GUI (Graphical User Interface)
There are various things that are excellent.

On the other hand, there is a need to execute these operating systems simultaneously on one computer. For example, in a large-scale computer, there is a demand that an operating system for executing online processing associated with actual work and an operating system for development be operated by one computer. Or GU
There is also a demand for simultaneously operating an operating system having the I and an operating system having an excellent real-time property.

However, it is assumed that each operating system independently manages computer resources, and coexistence of a plurality of operating systems is impossible without some mechanism.

As a mechanism for operating a plurality of operating systems on a single computer, a virtual computer system (OS series, Vol. 11 V
M, Yoshio Okazaki et al., Kyoritsu Publishing Co., Ltd.). In the virtual machine system, a virtual machine control program occupies and manages all hardware resources, and virtualizes them to configure a virtual machine. The control unit configuring the virtual machine virtualizes a physical memory, an input / output device, an external interrupt, and the like.

For example, the divided physical memory behaves as if it were a physical memory starting at address 0 for each virtual machine, and the device number for identifying the input / output device is also virtualized. Further, the storage area of the magnetic disk is also divided to realize the virtualization of the magnetic disk device.

Each operating system is scheduled by a control program to be executed on a virtual machine constructed by the control program. However, in the virtual computer system of a large computer, since the computer resources are to be completely virtualized and divided, the control part constituting the virtual computer is complicated and problematic.

[0008] Also, in the absence of special hardware support, privileged instructions such as control register setting and input / output instructions issued by an operating system running on a virtual machine must be emulated by a virtual machine control program. Therefore, the overhead increases, which is a problem. In fact, in a large-scale computer on which a virtual computer is mounted, a special processor function and hardware such as microcode are added for the virtual computer to reduce overhead. The virtual computer system is complicated because it aims to completely virtualize computer resources, and furthermore, a special hardware mechanism is required for improving the performance of the virtual computer, which is a problem.

On the other hand, there is a microkernel as a technique for providing an interface of a plurality of operating systems with one computer. In the microkernel,
On the microkernel, an operating system server that provides an operating system function to be shown to the user is constructed, and the user utilizes computer resources via the server. By preparing a server for each operating system, various operating system environments can be provided to the user.

However, in the microkernel system, it is necessary to newly construct an operating system server according to the microkernel. Often, you will need to change your existing operating system to run on a microkernel, but scheduling,
The core part of the kernel, such as memory management, is also changed, and there are many changes, and since the change extends to the core part of the operating system, the change operation is complicated, not easy, and is a problem.

The operating system server uses the service of the microkernel,
This is not a normal operating system, resulting in overhead and reduced performance.

[0012]

The conventional virtual computer system relies on a method of virtualizing all computer resources in order to simultaneously operate a plurality of operating systems. However, this method has a problem that the control program becomes complicated. Furthermore, since this method requires emulation of privileged instructions, special hardware is required to obtain performance, which is a problem.

The present invention realizes simultaneous execution of a plurality of operating systems without special hardware by changing the initialization processing portion and the interrupt management portion of the operating system, and adding an interrupt management program. In the present invention, emulation of privileged instructions is not required, so that execution of each operating system does not involve new overhead.

According to the present invention, a function that complements the first operating system can be easily added, and a high-performance computer system can be constructed. Furthermore, unlike the device driver, a function that operates completely independently of the first operating system can be incorporated, so that a high-reliability function independent of the first operating system can be added.

Further, in a method of configuring a plurality of multi-operating system environments by a microkernel system,
There is a problem that it is difficult to construct an operating system server that provides an interface for each operating system. According to the present invention, the change to the operating system is limited to only the initialization part and the interrupt management part, so that a multi-operating system environment can be easily configured.

[0016]

According to the present invention, a first OS reserves computer resources such as a physical memory and an external device required by a second OS, and a management program independent of both OSs. By intercepting an external interrupt, determining which OS's interrupt handler should be activated based on the interrupt factor, determining the timing of activating the interrupt handler based on the execution state of the OS, and determining each OS based on the determined timing.
By starting the interrupt handler of
Is operated by one computer.

[0017]

Embodiments of the present invention will be described.

An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing a configuration of a computer 100 according to the embodiment of the present invention.

The computer 100 includes a processor 101, a main storage device 102, a bus 109, an interrupt signal line 110, a clock interrupt generator 111, and an interrupt control device 11.
2. It is composed of a storage device 118 for storing a boot procedure and an interrupt bus 119.

The interrupt signal line 110 connects an external input / output device and the interrupt control device 112. When an external device generates an interrupt, the interrupt control device 112 receives a signal via the interrupt signal line 110, and the interrupt control device 112 digitizes this signal and passes it to the processor 101 via the interrupt bus 119.

The clock interrupt generator 111 generates a periodic interrupt.

The interrupt control device 112 receives an interrupt request from an external device, generates a numerically-defined interrupt signal according to the request source, and sends it to the processor 101. It is also assumed that an instruction from the processor 101 can prevent an interrupt signal from a specific device from being notified to the processor 101.

The processor 101 comprises an arithmetic unit 103, an interrupt table register 104, a page table register 105, and an address conversion unit 106.

The interrupt table register 104 indicates a virtual address of the interrupt table 107.
Although details of the interrupt table will be described later, the start address of the interrupt handler for each interrupt number is recorded. In FIG. 1, the connection between the interrupt table register 104 and the interrupt table 107 is indicated by a broken line.
This is because the interrupt table register 104 indicates the virtual address of the interrupt table. When an interrupt occurs, the processor 101 receives a digitized interrupt number from the interrupt controller 112. Using this number as an index, an interrupt handler address is obtained from the interrupt table 107, and control is passed to the interrupt handler.

The page table register 105 points to the page table 108. The page table register 105 stores the physical address of the page table 108.

The address translator 106 receives the instruction address requested by the arithmetic unit or the address where the operand is stored, and
The virtual-to-real address conversion is performed based on the contents of the page table 108 indicated by the reference numeral 05.

The computer 100 has a keyboard 113, a display 114, and a magnetic disk 1 as external input / output devices.
15, other external devices 116 and 117 are connected. Devices other than the display 114 are connected to the interrupt control device 112 via the interrupt signal line 110.

The contents of the main storage device 102 will be briefly described. At present, two operating systems are operating on the computer 101. These will be referred to as a first operating system and a second operating system, respectively. When the computer is started, the first OS
Are set to be activated, and the external devices 116 and 117 are devices managed by the second OS.

The first OS reserves a physical memory area for other operating systems, in this case, for the second OS in an initialization process at the time of startup. That is, the physical memory area is secured so that the first OS cannot use the physical memory area reserved for the second OS. FIG.
This shows a state where the second OS is loaded in the deprived area.

Further, in the initialization process of the first OS, the interrupt numbers and input / output addresses used by the external devices 116 and 117 from the first OS are reserved as already used.

The first OS has a common area that can be referred to from all operating systems. The common area stores an interrupt table 107, an interrupt management program, an interrupt handler, an interface module that can be called from each operating system, and the like.

An outline of the operation of the embodiment of the present invention will be described. In the present embodiment, the second OS is the first OS
Operate with priority over To operate with priority means that the first OS can operate only when the second OS is in the idle state. Unless the processing of the second OS is completed, the first OS cannot operate.

When a device managed by the second OS generates an interrupt, the processing of the first OS is interrupted, and control is transferred to the second OS. Even if the first interrupt occurs during the execution of the second OS, the interrupt processing is postponed until the first OS is executed.

Further, the first OS and the second OS are clearly separated from each other so that they cannot access each other except for a common area where an interrupt handler and the like are arranged. This prevents the two operating systems from accidentally accessing each other's area and causing a failure.

Hereinafter, embodiments of the present invention that realize the above functions will be described.

FIG. 2 is a diagram conceptually showing a relationship between two operating systems according to the embodiment of the present invention. Each operating system has an independent address space. 201 is a virtual space of the first OS, and 202 is a virtual space of the second OS. Here, the real storage corresponding to the space 202 of the second OS is the area of the second OS in the main storage 102 in FIG.

The common area 203 is mapped to a part of the virtual space. The real storage corresponding to the common area 203 is the area shown as the common area of the main storage 102 in FIG.
The common area 203 is originally a part of the area of the kernel of the first OS. The procedure for loading the second OS creates a page table for the second OS so that the common area 203 is mapped to the address space 202 when the address space 202 is constructed. This procedure will be described later.

FIG. 2 shows hardware managed by each operating system. The first OS manages the keyboard 113, the display 114, and the magnetic disk 115, and the second OS manages the input / output devices 116 and 117. Clock 11
1 and the interrupt controller 112 are originally the first OS
Is the hardware managed by the common area 203
Indicates that the program inside manages.

Next, the configuration of the page table will be described. FIG. 3 shows a configuration of the page table according to the embodiment of the present invention.

Reference numeral 300 denotes a page table. The page table 300 has an entry describing each virtual page for each virtual page in the virtual address space of the processor 101. Each entry is composed of a valid bit 301 and a physical page number 302.

The valid bit 301 indicates whether a physical page corresponding to the virtual page is allocated, that is, whether virtual-real address conversion is possible. For example, the virtual page 3 of the page table 300 has no valid bit set, indicating that there is no physical page corresponding to the virtual page 3. Valid bit 301
When an access to a virtual page for which is not set occurs, the processor generates a page fault.

The physical page number 302 records a physical page number corresponding to a virtual page.

The address translation unit 106 translates a virtual address generated by the arithmetic unit 103 into a real address with reference to the contents of the page table pointed to by the page table register 105. The processor 101 refers to the main storage device 102 based on the real address obtained by the conversion.

By switching the page tables, an independent space can be constructed, and a space for the first operating system and a space for the second operating system shown in FIG. 2 can be constructed. Also,
Regarding the common area 203, a portion corresponding to the common area of the page tables of both operating systems includes:
If the same physical page is set to be mapped, a common area can be realized.

Next, the configuration of the interrupt table will be described. FIG. 4 shows the configuration of the interrupt table.

Reference numeral 400 denotes an interrupt table. The interrupt table 400 records a virtual address 401 of an interrupt handler for each interrupt number received by the processor 101 from the interrupt controller 112. When receiving an interrupt request from the interrupt control device 112, the processor 101 obtains the address of the interrupt handler corresponding to the interrupt number from the interrupt table 400 indicated by the interrupt table register 104, and transfers control to the address to execute the interrupt processing. To start.

FIG. 5 shows the interrupt control device 112. The interrupt control device 112 has an interrupt mask register 501 and a selection device 502.

An input / output device that generates an interrupt is connected to an interrupt control device 112 through an interrupt signal line 110. The priority of the interrupt generated by the input / output device is determined depending on which signal line of the interrupt signal line 110 is connected. Here, it is assumed that the interrupt signal corresponding to the interrupt 0 is the interrupt having the highest priority.

The interrupt signal line 110 is connected to the selection device 502
Connected to Upon receiving the interrupt signal, the selecting device 502 records that there is an unprocessed interrupt until the processor notifies that the interrupt has been received.

The interrupt mask register 501 records whether an interrupt generated by an input / output device may be notified to a processor. The interrupt mask register 501 can be set by an input / output instruction from the processor 101.

The selection device 502 is connected to the interrupt signal line 110
When the interrupt request is received from the CPU and when the contents of the interrupt mask register 501 are rewritten,
Is compared with the contents of the interrupt mask register 502 to determine whether or not to notify the processor of the interrupt. Specifically, the selection device 50
Among the unprocessed interrupts recorded in No. 2, the interrupt mask register 501 is set to enable interrupts, and the interrupt is notified to the processor in order from the interrupt having the highest priority. For the selected interrupt, the selecting device 502 sends a numerical signal corresponding to the interrupt signal to be notified to the processor 101 via the interrupt bus 119.

When receiving an interrupt, the processor 101 can cancel the unprocessed interrupt record recorded in the selecting device 502 by the input / output instruction.

Next, a description will be given of a computer boot procedure in the embodiment of the present invention.

The beginning of the boot procedure is stored in a read-only storage device 118. Storage device 11
8 is connected to the processor 101 via the bus 109 so as to be mapped to a predetermined address in the physical address space of the processor. In this procedure, a hardware configuration is detected, and a program for loading an operating system kernel is loaded into a main memory.

When the processor 101 is reset, the processor 101 transfers control to a predetermined physical address. The storage device 118 stores a program to be executed at this time, and is mapped to a physical address space so that control can be passed to the program when the processor 101 is reset.

The program stored in the storage device 118 loads the kernel loader of the first OS stored in the magnetic disk device 112 into the main storage device 102 and executes it. The kernel loader is used for the magnetic disk drive 112
The program stored in the storage device 118 at a predetermined position can easily find this.

The processing procedure of the kernel loader will be described. FIG. 6 is a flowchart showing a processing procedure of the kernel loader of the operating system according to the embodiment of the present invention.

The kernel loader is configured to understand the file system structure of the operating system, specify the storage location of the file from the file name, and read the file into the main memory.

The processing procedure of the kernel loader will be described. First, a main storage list 1101, a load module list 1104, and a device list 1102 to be passed as parameters to the kernel are initialized, and a page table area for the kernel is allocated (step 601).
The configuration of the three lists will be described later.

The main storage list 1101 stores the main storage device 10
This is a data structure indicating the usage status of the second memory. When the kernel loader allocates physical memory in the subsequent processing, the kernel loader refers to the main storage list 1101 and changes it.

Next, inspection of the hardware configuration (step 602) and creation of hardware configuration data (step 603) are performed. In step 602, the hardware checks how the computer 100 is connected. In the following step 603, a device list 1102, which is a data structure relating to the hardware configuration, is created based on the result of step 602. The operating system kernel performs kernel initialization processing with reference to the device list 1102.

Next, the configuration information 700 of the operating system kernel is read from the magnetic disk device 112, and the address of the configuration information is set in the parameter table 1100 (step 604). The kernel of the operating system may be composed of a plurality of files such as a file of the kernel itself and a file of another device driver. Configuration information 700
Is stored on the magnetic disk 112 with a predetermined file name, and the load program can find it.

FIG. 7 shows the data structure of the kernel configuration information according to the embodiment of the present invention. Reference numeral 700 denotes the contents of a file recording kernel configuration information. The configuration information file 700 stores data referred to by the kernel loader and the operating system. The stored data is given a name, and the program can obtain the corresponding data from the name. In the example of FIG. 7, the name is the object file (70
There is an entry 1), and its data is stored in 702. It is also assumed that data (704) for the second OS is stored in the secondary OS.

The description of the processing procedure of the kernel loader will be continued. After reading the configuration information 700, all the kernel configuration files stored in the data named object file in the configuration information 700 are read into the main storage device 102 (step 606).
An entry is added to the load module list 1104 (step 607), and a page table for the kernel is set (step 608). Here, kern
Load the object files with the file names el, driver1, and driver2.

The addition of the load module list entry and the setting of the page table for the kernel are performed in the main memory 10.
2 according to the data stored in the object file loaded. The object file constituting the kernel includes a virtual address for mapping the contents of the file, the size of the file, and the like.
Build a page table by referring to this. The data structure of the object file will be described later.

Finally, the page table register 105
Is set to the address of the constructed page table, the processor is shifted to the virtual address translation mode (step 609), and the constructed main storage list 1101, device list 1102, kernel configuration information table 1103, and load object list 1104 The control is passed to the initialization routine of the kernel using the parameter table 1110 composed of a set as a parameter (step 61).
0). The entry point of the kernel is recorded in data in the kernel file.

Next, the structure of an object file constituting the kernel will be described. FIG. 8 is a diagram showing a structure of an object file constituting a kernel according to the embodiment of the present invention.

Reference numeral 800 denotes the entire object file. The object file 800 includes a header portion 801 to 811 and a section portion 812 to 813.

The structure of the header will be described. The header map address 801 and the header size 802 describe the storage location of the header portion of the object file 800 in the kernel space. The header portion is read at the address recorded in the header map address 801.

The initialization entry 803 records the address of the initialization routine of the object file 800. When the kernel calls the initialization routine of each object file at the time of kernel initialization, the kernel refers to the initialization entry 803 of each object file to find the initialization routine.

The section number 804 records the number of sections included in the object file 800. A section is a continuous data area in an object file, and the mapping of the kernel to the virtual space is determined in units of the data area. For example, the object file includes a section storing the execution code and a section storing data referred to by the object file. These sections are created by the compiler when the object file is created.

The external reference table offset 805 and the external reference table size 806 are the external reference table 810 for storing information of public reference of another object file referred to by the execution code in this object file.
Is described. The external reference table 810 is included in the header part of the object file 800, and the external reference table offset 805 records the offset of the external reference table 810 from the head of the header.

The public reference table offset 807 and the public reference table size 808 describe a public reference table 811 that stores information on modules and data that this object file discloses to execution codes of other object files. I have. Public reference table 81
1 is included in the header portion of the object file 800, and the public reference table offset 807 records the offset of the public reference table 811 from the head of the header.

The section data 809 stores data on each section included in the object file 800. The number of section data is equal to the number of sections 804. The structure of the section data will be described later.

After the section data, an external reference table 810 and a public reference table 811 follow to form a header portion.

After the header part, main bodies 812 and 813 of each section are stored.

The configuration of section data 809 will be described. The section start offset 820 and the section size 821 are defined in the object file 800 by:
The start offset of the section and the size of the section are recorded.

The section is mapped in the kernel virtual space so as to be located at the address recorded in the section map address 822. The section name 823 stores a character string indicating the name of the section.

The structure of the external reference table will be described. FIG. 9 shows the structure of the external reference table. At the head of the table 810, the number 901 of external reference information included in this table is stored.

Subsequently, an object file name 902,
An external reference name 903 is stored. The object file name 902 and the external reference name 903 correspond to the character string table 9
05, and the actual name of the character string is stored in the character string table 905.

The external reference address 904 stores the actual address of the external reference described by the external reference entry. When loading the object file into the main memory, the kernel refers to the public reference table of the object file including the external reference, and performs a function,
Alternatively, the address of the data is obtained and set as the external reference address 904. The execution code of the object file is compiled so as to refer to the address stored in the external function address 904, call a function in another object file, and refer to data.
Functions in other object modules can be executed and data can be referenced.

The object file name 902, the external reference name 903, and the external reference address 904 define one external reference, and these entries are continuously arranged by the number recorded in the external reference number 901. . After that, the character string table 905 is stored. The character string table stores character strings of object file names and external reference names.

The structure of the public reference table will be described. FIG. 10 is a diagram showing the structure of the public reference table.

At the head of the table 811 is recorded the number 1001 of reference names that are made public to other object modules by the public reference table 811. One public reference is a public reference name 1002 and a public reference address 1
003. The public reference name 1002 stores an offset value to the character string table 1004,
The actual name of the character string is stored in the character string table 1004. The public reference address 1003 stores an address corresponding to this reference.

Next, the hardware configuration data created by the boot procedure starting from step 601 and the configuration of load object data will be described. FIG. 11 is a diagram showing the configuration of hardware configuration data and load object data.

The parameter table 1100 is a data structure created by the kernel loader. The three lists starting from the parameter table 1100 are arranged in the virtual space of the kernel constructed by the loader, and can be referred to from the kernel.

The parameter table 1100 holds a pointer to the head of the three lists constructed by the loader and a pointer to one table. The three lists are a main storage list 1101, a device list 1102,
One table in the load object list 1104 is a kernel configuration information table 1103.
Each will be described.

The main storage list 1101 is a list of main storage block description data 1110. The main storage block description data 1110 includes a base address 1111, a block size 1112, a block usage status 1113, and a pointer 111 to the next main storage block description data.
4.

The main storage block description data records the usage status of a certain continuous main storage area. The base address 1111 indicates the start physical address of the continuous area, and the block size 1112 stores the size of the continuous area. The block usage status 1113 stores a value indicating whether the continuous area is unused or has been allocated by the loader. The list is constituted by the pointer 1114 to the next entry. In FIG. 11, the entry next to 1110 is 1120. By referring to the main storage list 1101, the use state of the physical memory can be known.

The device list 1102 stores data relating to the hardware devices detected by the kernel loader, and is created in step 603. The device list 1103 is a list including device data 1150. The device data 1150 includes a device type 1151, device information 1152, and a pointer 1153 to the next device data.

The device type 1151 stores a value indicating the type of the device described by the device data entry 1150. Device information 1152
Stores data specific to the type of device. For example, an interrupt number or an I / O address corresponds to this. The list is constituted by the pointer 1153 to the next entry.

Pointer 1 to kernel configuration information table
103 indicates the contents of the kernel configuration information file 700 read into the main memory 102 by the kernel loader.

The load object list 1104 holds data relating to the object file loaded into the main memory by the kernel loader. The load object list is a list of the load object data 1130. The load object data 1130 includes an object file name 1131 and an object address 11
32, and a pointer 1133 to the next load object data.

The object file name 1131 is the file name of the object file described by the load object data 1130. The object address 1132 stores the address of the kernel space where the header area of the object file is loaded. Then, a pointer 1133 to the next entry
Constitutes a list.

The load object list 1104 is created at the same time that the kernel loader reads the object file constituting the kernel (step 60).
7).

Next, a procedure for initializing the first OS according to the embodiment of the present invention will be described. FIG. 12 is a flowchart showing a procedure for initializing the first OS.

First, the load object list 11 in the parameter table 1100 passed as a parameter
Referring to FIG. 04, the external reference address of the object file loaded by the kernel loader is resolved (step 1201). In the address resolution, the external reference address 904 of the external reference table 810 in each object file is determined. The address is determined with reference to the public reference table 811 of each object file.

In the following step 1202, the parameter table 1 passed as a parameter at the time of kernel startup
100 with reference to the main storage list 1101 of the second OS
A main storage area for

Specifically, the kernel configuration information table 7
The information of the second OS is extracted from 00. In the example of FIG.
The configuration information of the second OS is stored in 704. The size of the main memory to be secured is determined with reference to the configuration information 704. Then, the contents of the empty block entry in the main storage list 1101 are changed, and the main storage area is allocated. This process is performed before the first OS starts managing free memory.

As a result, when viewed from the first OS, the main storage area allocated to the second OS does not exist, and is not referred to by the first OS. Therefore, the allocated area becomes a main storage area that can be used freely by the second OS. This is the second OS in FIG.
Area.

In the next step 1203, the data structure in the kernel is initialized. This initialization includes initialization of a device management table described later.

In step 1204, a device managed by the second OS is reserved. Here, to make a reservation means to make it unusable from the first OS. Specifically, registration in the device management table managed by the first OS is performed.

The device resources managed by the second OS are determined by referring to the configuration information of the second OS stored in the table 700 indicated by the kernel configuration information table 1103 of the parameter table 1100. In this embodiment, the data stored in 704 in FIG. 7 corresponds thereto.

The device management table will be described.
FIG. 13 is a diagram showing the structure of the device management table of the first OS. The device management table has two data structures, an interrupt vector management table 1300 and an I / O address management list 1310.

The interrupt vector management table 1300 is
For each interrupt number accepted by the processor 101, a value indicating whether the first OS uses the interrupt number is stored. The kernel checks this table 1300 when the device driver requests an interrupt number at initialization, checks whether the requested interrupt number is used, and uses the requested interrupt number only when not. Grant rights to the device driver. If it is described that the device has already been used, the device cannot be used from the first OS.

The input / output devices 116 and 117 shown in FIG. 2 will be described as an example. Assume that I / O devices 116 and 117 request interrupt numbers 4 and 5, respectively. I / O device 1
Devices 16 and 117 are devices managed by the second OS. The interrupt numbers requested by the input / output devices 116 and 117 are recorded in the configuration information 704 of the second OS in the kernel configuration information table 700. In step 1204, a value indicating that it is being used is stored in the entry of the interrupt numbers 4 and 5 in the interrupt vector management table with reference to the configuration information 704. This processing is performed by the first O
The first OS cannot access the input / output devices 116 and 117 because the process is performed before S starts device management, and the devices 116 and 117 can be controlled by the second OS. .

The same applies to the I / O address management list 1310. I / O address management list 1310
Is a list composed of entries 1320 representing I / O address ranges. Entry 1320 is the first OS
Consists of an I / O address range 1321 used by the user and a pointer 1322 to the next entry for composing the list. As in the case of the interrupt vector management table 1300, when the device driver requests an I / O address range at the time of initialization, the kernel checks whether the address range is already used by using the I / O address management list 1310, In some cases, an entry is added to this list 1310 to grant use permission.

Since the I / O address range requested by the device managed by the second OS is stored in the kernel configuration information table 700 in the same manner as the interrupt number, the requested address can be known by referring to it. , The first OS
Can reserve I / O addresses before starting device management.

By the processing in step 1202, the first O
A space dedicated to the second OS completely independent of S can be constructed. Further, the processing in step 1204 makes it impossible for the user program operating on the first OS to access the devices managed by the second operating system, in this example, the input / output devices 116 and 117. Also, it is possible to prohibit the introduction of a device driver that uses the interrupt numbers and I / O addresses of the devices 116 and 117.

The effect of the two steps is as follows.
It becomes possible to introduce the second OS into a part that the first OS does not care about.

The following steps 1205 to 1207 are the same as the ordinary operating system initialization processing. In the initialization of the system device in step 1205, the system device that is directly managed by the kernel is initialized. The system device is a device that is indispensable for execution of the first OS, such as a clock interrupt, and assumes that the first OS always exists.

In step 1206, each initialization entry is executed for the object file loaded by the kernel loader. The initialization entry address is stored in the header of the object file. Finally, an initial process is created (step 120).
7).

Next, a procedure for loading the second OS according to the embodiment of the present invention will be described. FIG. 14 is a flowchart showing a procedure for loading the second OS.

First, it is necessary to read the object file of the second OS into the physical memory area allocated for the second OS. However, since the physical memory area of the second OS cannot be written from the first OS as it is, the allocated physical memory area is temporarily mapped in the virtual space of the first OS (step 1401).

In step 1402, the file is read into the mapped area by using the file reading procedure of the first OS.
The object file of the second OS is read. In addition,
The format of the object file of the second OS is the first O
It is assumed that the format is the same as the object file format 800 of S.

Next, a page table for the second OS is created (step 1403). This page table is also created in the area for the second OS. At this time, a page table is constructed so that a portion shared with the first OS can be referred to from the space of the second OS.

In the common area 203, an area loaded with a device driver (hereinafter referred to as a support driver) for executing interrupt processing and management of common data is set as the common area 203. The address at which the device driver is loaded can be known from the load object list 1104. In the following step 1404, the external reference of the kernel of the second OS is resolved. However, other object files that can be directly referred to by the second OS are only functions and data located in the common area 203, that is, only public references of the support driver. Therefore, here, the external address 904 of the external reference table 810 of the kernel object file of the second OS is determined with reference to the public reference table 811 stored in the header part of the object file of the support driver.

Next, the address of the public reference of the second OS is written in the external reference address table assigned to the data area of the common area. The support driver serving as the common area is read as the device driver of the first OS according to the mechanism of the first OS, and cannot be linked to the public reference of the second OS.

In this case, a table for storing necessary external reference names and corresponding external addresses in the data area of the support driver is prepared in advance. The execution code of the support driver refers to this table and
A call is made to the public function of the kernel of S, and the public data is referred to. Then, when the second OS is loaded, the publicly referenced address of the support driver is written in the external address column of this table.

Thus, the setting of the second OS area is completed.
Release the mapping of the physical memory area for the second OS, which is mapped to the kernel area of the first OS (Step 1)
406).

Next, the OS context table 1510
And the OS identification variable 1530
Is set (step 1407). The OS context is a data structure referred to when switching the execution operating system, and includes a page table address value and an initial value of a stack pointer. Here, the address of the page table that maps the second OS is set as the page table register value, and the initial address of the kernel stack of the second OS is set as the stack pointer value. The OS identification variable 1530 stores a value indicating that the first OS is being executed. The OS context table 1510 and the OS identification variable 1530 will be described later.

Next, the initialization module of the second OS is executed (step 1408). This involves switching the operating system space. The switching of the operating system will be described with reference to another flowchart. Further, the initialization module of the second OS is publicly referenced, and the support driver can know the address.

Finally, in step 1409, the address of the interrupt handler of the first OS registered in the current interrupt table 104 is stored in the interrupt identification table 1.
Copy to the handler column 522 of 520, and change the interrupt table register value to the address of the interrupt table assigned to the support driver. This is performed by changing the interrupt table register 104 of the processor 101.

The reason why the interrupt table is changed to the table in the support driver is that the interrupt table must always exist in the virtual address space of the processor 101 regardless of which operating system is executing when the interrupt occurs. It is. The interrupt handler registered in the interrupt table is also located in the support driver. Step 140
In step 3, the virtual area of the second OS is mapped to the common area 203, so that it can be referred to at any time. The interrupt processing of the support driver will be described later.

In step 1409, the first OS
Also change the interrupt management information of. Specifically, the data structure related to the interrupt inhibition level is changed, which will be described later.

The data structure stored in the common area 203 will be described. FIG. 15 is a diagram showing a data structure stored in the data area 1500 of the common area 203. This will be described in order according to FIG.

Reference numeral 1510 denotes an OS context table. The OS context table 1510 stores the first O
Data required for switching between S and the second OS is held. In this embodiment, it is assumed that the first OS can run only when the second OS is in an idle state. In this case, switching to the second OS occurs at some point during execution of the first OS, and control may be returned to the first OS at the end of execution of the second OS.

Therefore, only one context needs to be stored for each. For the context of the first OS, if the page table register value 1511 and the stack pointer value 1512 at the time when the OS switching is requested are stored, the first OS is controlled by the first OS after the execution of the second OS is completed. Can be restored.

Further, when the control is switched from the first OS to the second OS, the second OS is not operating. Therefore, in the context of the second OS, both the page table address and the stack pointer may be fixed values. The page table register value 1513 and the stack pointer value 1514 of the second OS are set when loading the second OS (Step 1407).

Reference numeral 1520 denotes an interrupt identification table. The interrupt identification table 1520 records, for each interrupt number of the external interrupt, a value 1521 indicating which operating system processes the interrupt, and an address 1522 of the interrupt handler. When an external interrupt occurs, the interrupt handler in the common area 203 captures the interrupt, and the interrupt identification table 15
With reference to the processing OS 1521, which OS is to be processed, control is passed to the address of the handler 1522. Details of the interrupt processing will be described later.

An OS identification variable 1530 stores a value indicating the operating system being executed. This variable 1530 is set each time the OS is switched in the OS switching procedure starting from step 1601. In the interrupt processing, an interrupt processing procedure is determined with reference to the variable 1530.

Reference numeral 1540 denotes a delayed interrupt status variable indicating whether an interrupt of a device managed by the first OS has occurred during execution of the second OS. This variable 1540
Records which interrupt number has occurred. The OS switching procedure examines this variable 1540 when the execution of the second OS ends, and determines whether to start the interrupt processing (Step 1608).

The procedure for switching the operating system will be described. FIG. 16 is a flowchart illustrating a procedure for switching an operating system according to the embodiment of the present invention. This switching procedure is called during the execution of the first OS, and switches the second OS.

The procedure shown in FIG. 16 receives, as arguments, the address of the module of the second OS to be executed after switching to the second OS and the arguments to be passed to the module. The address of the module of the second OS can be known by referring to the external reference address table set in the common area 203.

First, in the first step 1601, the current stack pointer value and page table register value are
It is stored as the context of the first OS in the S context table 1510. In step 1601, the current stack pointer value is stored in 1512 and the current value of the page table register 105 is stored in 1511.

For other register contexts, the OS
There is no need to save it in the context table 1510.
If necessary, it may be stored in the stack of the first OS.

After saving the stack pointer and the page table register value, in step 1602, the page table register 105 is set with the address of the page table that maps the second OS to the virtual space. This is the OS
It is recorded in 1513 of the context table 1510. Further, a stack pointer is set for the second OS. This is also stored in the stack pointer 1514 of the second OS in the table 1600.

In the next step 1603, the delay interrupt status variable 1540 indicating the interrupt status of the first OS is cleared. The status variable 1540 is a variable that records the state of occurrence of an interrupt from a device managed by the first OS, which has occurred during execution of the second OS. This is cleared before executing the second OS.

Then, the O indicated by the OS currently being executed is
The S identification variable 1530 is rewritten to a value indicating the second OS (Step 1604). Stack pointer, page table register 105, and OS identification variable 1530
Must always be consistent, so
Steps 1601 to 1604 up to this point must be executed with all external interrupts disabled.

In the following step 1605, control is transferred to the address of the module passed as an argument, and control is passed to the second operating system. In this embodiment of the present invention, it is assumed that the first OS can be executed only when the second OS is not running, that is, when the second OS is in an idle state. Therefore, when the processing of the second OS ends, the control returns to step 1606.

At step 1606, step 1601
To restore the page table register value 1511 and the stack pointer value 1512 stored in the OS context table 15100 respectively. Following step 1607
Then, the OS identification variable 1530 is changed to a value indicating that the first OS is running. The processing of these two steps must also be executed with interrupts disabled.

Next, an external interrupt of a device managed by the first OS, which occurs during execution of the second OS, is processed. First, in step 1608, the delay interrupt status variable 1540 is checked to determine whether an interrupt has occurred. If not, the OS switching procedure ends, and the process returns to the calling source.

Otherwise, if an interrupt has occurred, step 1609 is executed. In this step, the fact that there is an unprocessed interrupt is recorded in the postponed interrupt status variable managed by the first OS for the interrupt that occurred during the execution of the second OS. Subsequently, the interrupt processing of the first OS is started (step 1610). When all the interrupt processes are completed, the process returns to the call source of the OS switching procedure.

The interrupt processing according to the embodiment of the present invention will be described. FIG. 17 is a flowchart illustrating an interrupt processing procedure according to the present embodiment. A module that executes this procedure is registered in the interrupt table 107 of the processor as an interrupt handler. Further, this interrupt handler is arranged in a common area 203 that can be referred to by both operating systems.

When an external interrupt occurs, the processor 10
When the interrupt handler is activated by step 1, the interrupt handler examines the cause of the interrupt, and determines whether the device that generated the interrupt is a device managed by the first OS or a second OS.
It is determined whether the device is managed by the device (step 1701).
This determination is made by referring to the OS column 1521 in the interrupt identification table 1520 using the interrupt number as an index. If the device is a device of the first OS, the process proceeds to step 1702, and if the device is a device of the second OS, the process proceeds to step 1705. For example, in FIG. 15, if the interrupt number is 1, the interrupt is the first OS interrupt, and if the interrupt number is 4, the interrupt is the second OS.

If the interrupt is a device interrupt of the first OS, step 1702 is executed. In step 1702, the OS that was being executed when the interrupt occurred is determined. This determination is made with reference to the OS identification variable 1530. If the OS being executed is the first OS, the process proceeds to step 1703. If the OS being executed is the second OS, the process proceeds to step 1704.

The process starting from step 1703 is a process performed when a device managed by the first OS generates an interrupt during execution of the first OS. Step 17
In 03, the context is set so that there is no processing starting from step 1701 and the interrupt handler of the first OS appears to be directly controlled by the processor 101. Here, the context indicates the contents of the stack and the contents of the register. And the first OS
Control to the interrupt handler of The address of the interrupt handler of the first OS is stored in the interrupt identification table 152.
0 is stored in the handler field 1522. For example, if the interrupt is interrupt number 1, the handler address is obtained by referring to the interrupt identification table using 1 as an index.

In this case, control is not returned to the procedure starting from step 1701, and the first OS continues the processing.

If the device managed by the first OS generates an interrupt during execution of the second OS, step 1704 is executed. In step 1704, the interrupt number of the device that caused the interrupt is recorded in the delay interrupt status variable 1540. This completes the processing of the interrupt handler. The processing of the interrupt in this case is executed OS
Is switched to the first OS (step 1608).

If the generated external interrupt is an interrupt of a device managed by the second OS, step 1705
To check which OS is running. Here, the OS being executed is determined based on the OS identification variable 1530. If the first OS is running, step 170
If the second OS is being executed, the process proceeds to step 1711.

If an interrupt of a device managed by the second OS occurs during the execution of the second OS, step 17
Step 11 is executed. Step 1711 activates the interrupt handler of the second OS. The address of the interrupt handler of the second OS is recorded in the handler column 1522 of the interrupt identification table 1520. When the second OS interrupt handler process ends and control returns, this interrupt handler also ends, recovers the context at the time of the interrupt, and returns control.

If an external interrupt of a device managed by the second OS occurs during the execution of the first OS, step 1
Step 706 is executed. In this case, the process of the second OS is executed with priority over the execution of the first OS.

First, in step 1706, the context is saved. Here, the context indicates the contents of the stack and the contents of the registers necessary for restoring the interrupted state when returning to the first OS after the completion of the interrupt processing. This context is the primary OS
To the kernel stack.

Subsequently, switching of the execution OS and the second OS
Of the interrupt processing of step (1707).
1708). This is performed by a procedure starting from step 1601.

When the processing of the second OS is completed, switching to the first OS is executed (step 1709), and the context at the time of interruption is restored (step 171).
0), restart the processing of the first OS. Step 1709
Is not necessarily executed in the same module as the process starting from step 1701. The process returns to this module by switching to the first OS.

The processing of a clock interrupt shared by two operating systems will now be described. The clock interrupt is captured by an interrupt handler in the common area. In this interrupt handler, first, an interrupt handler for a clock interrupt of the second OS is executed. The interrupt handler of the second OS is the handler 2 column 15
23. When the execution of the interrupt handler of the second OS is completed, the interrupt process of the first OS is executed by the process starting from step 1702 in FIG.
The address of the first interrupt handler is the handler field 152
2 is stored.

Next, the interrupt control portion of the first OS will be described. This is a process for preventing the interrupt of the device managed by the second OS from being erroneously prohibited by the interrupt control of the first OS.

[0158] It is assumed that the first OS controls the interrupt by the interrupt disable level. The interrupt prohibition level is a mechanism required to realize exclusive control between a part that operates as an extension of interrupt processing in the kernel of the operating system and a part that does not.

The first OS realizes the interrupt inhibition level by programming the interrupt control device 112.
That is, the interrupt mask register 502 of the interrupt controller 112 is programmed to selectively mask external interrupts. Since the first OS does not know anything about the second OS, when the first OS changes the interrupt disable level, the interrupt of the device of the second OS may be masked. To prevent this, the first O
Change the interrupt control part of S.

FIG. 18 shows a data structure managed by the first OS for realizing the interrupt disable level. 1
Reference numeral 800 denotes an interrupt disable level table. Each interrupt level is represented by a numerical value, and indicates which external interrupt is masked for each interrupt disable level. The checked portion of the table 1800 indicates that interrupt masking is set. For example, the interrupt disable table 180
0 indicates that no interrupt is masked at the interrupt inhibition level 0. Further, the interrupt inhibition level 3 indicates that interrupts of interrupt numbers 3 to 5 are masked by the interrupt control device 112. At interrupt disable level 5, all interrupts are masked by the interrupt controller 112.

In the present invention, the interrupt disable level table 1800 is changed when the second OS is initialized (step 1409). In step 1409, the second OS
Changes the interrupt prohibition level table so that the first OS does not mask those interrupts generated by the devices managed by. Specifically, referring to the OS column 1521 of the interrupt identification table 1520,
The check of the interrupt disable level table 1800 for the interrupt number managed by the second OS is cleared.

In this example, interrupt numbers 4 and 5 are interrupts processed by the second OS. Accordingly, the columns of the interrupt numbers 4 and 5 (1801 and 1
802) is cleared.

Thus, even if the first OS changes the interrupt disable level, the interrupt of the device managed by the second OS is not masked.

As described above, two operating systems can be operated simultaneously by one computer.

According to the present invention, when two operating systems are operated simultaneously by making a change to the first OS, the changed parts are the initialization part of the operating system kernel, the device resource reservation, and the interrupt inhibition control part. Because of the limitation, it is possible to easily operate the two operating systems.

In the method using a virtual computer, emulation of a privileged instruction is required to virtualize a physical memory and an I / O channel. However, if this is realized by software, there is a problem in that overhead is increased. The virtual machine system often has special hardware to reduce this overhead. However, in the present invention, for each device, an operating system that manages the device is determined in advance, and furthermore, a range that can be used for the physical memory is determined at initialization, so that the operating systems do not interfere with each other, The control by complicated software such as a virtual machine was abolished, and hardware for speeding up was eliminated.

According to the present invention, it is possible to easily add an OS that complements the function of the first OS. Also in the prior art, it is possible to add a new function to the kernel as a component of the first OS, for example, as a device driver. However, if the first OS is used as a component, there is a problem that the component can operate only under the control of the first OS. That is, when the first OS is stopped due to a failure, the added function module cannot operate.

According to the present invention, components for realizing a new function can be configured independently of the first OS.
Even if the first OS is stopped, only the functional module can continue to operate. This embodiment will be described later. If a functional module requiring reliability is incorporated as the second OS, the first OS
Even when S has stopped, it is possible to realize some kind of recovery processing. As described above, the present invention is an invention that can be a means for realizing high reliability of a computer system.

In this embodiment, the description has been given assuming that the second OS executes the process prior to the first OS. The first OS prioritizes the second OS by being able to operate only when the second OS is idle, and by always processing the interruption of the second OS immediately. Thus, even if the first OS is not suitable for real-time processing,
If an OS suitable for real-time processing is introduced as the second OS,
It is possible to construct a computer system having excellent real-time processing performance while utilizing the features of the first OS. For example, the first OS has an excellent GUI (Graphical User Inter
face) but lacks real-time processing performance, an operating system suitable for real-time processing that operates with priority over the first OS is introduced as the second OS, so that it has excellent GUI and real-time processing. A computer system with excellent processing can be constructed.

As described above, the present invention is a method for easily introducing a function lacking in the first OS without special hardware support, and the function is completely different from that of the first OS. Enables independent operation.

Next, a second embodiment of the present invention will be described. The second embodiment is an extension of the embodiment described above. In this embodiment, the first OS
It is feasible to introduce a second OS that continues to operate even if the OS is stopped due to a failure.

In addition to the first embodiment, a first OS execution state variable 1550 is placed in a common area. This variable 1550
Stores a value indicating whether the first OS is operating normally or not. This variable 1550 contains the second O
At the time of loading S, it is initialized to a value indicating a normal operation.

FIG. 19 is a flowchart showing a procedure for stopping the first OS according to the second embodiment of this invention.
This processing procedure is implemented by changing the module that executes the stop processing of the first OS.

First, when the first OS stop processing module is controlled, the first OS execution state variable 1550 is set to a value indicating that the first OS is stopped (step 1901). After that, the first OS stop processing is executed (step 1902). Finally, the interruption to the first OS is masked, the interruption of the device processed by the second OS is permitted (step 1903), and the process waits until an interruption occurs (step 1904). When an interrupt occurs, the execution OS is switched, and the second OS executes the processing.

Further, the execution OS switching procedure is changed.
In the first embodiment, the execution OS is switched according to the procedure starting from step 1601. In the second embodiment, after executing the module of the second OS in this procedure, that is, after step 1605, the first OS execution state variable 1550 is checked. Here, if the first OS execution state variable 1550 has a value indicating that the first OS is stopped, the process waits for an interrupt without executing the processing after step 1606.

With the above data structure and procedure, the first O
Even if S stops, the execution of the second OS can be continued. In this embodiment, the stop processing module of the first OS is changed. However, the module executed in the stop processing when the first OS stops due to an error is changed to stop the first OS. The same effect can be realized by detecting and waiting for an interrupt.

A third embodiment of the present invention will be described. In the embodiments described above, simultaneous execution of two OSs and the like are realized by changing the kernel body. In the third embodiment, the functions of the above embodiments are realized without changing the kernel body.

In an operating system that supports various types of hardware, hardware-dependent processing may be separated from the kernel itself and configured as another object file. For example,
When the interrupt control device 112 differs depending on the computer,
This is a case where the configuration of the bus 109 is different and the I / O address space is different for each computer.

FIG. 20 shows a case where such an operating system, that is, a code or data for absorbing a difference in underlying hardware such as an interrupt control device and a bus is in an object file separated from the kernel itself. FIG. 3 is a diagram showing a state of a kernel area of FIG.

In the kernel area 2000, the processor 1
01 modules executed in the kernel mode and data structures managed by the operating system. The kernel body 2001 has codes and data for performing hardware-independent processing such as memory management, process scheduling, and file system. Kernel body 2001 and hardware dependent part 200
2, a module which must be provided by the hardware dependent unit 2002 and a rule regarding a module provided by the kernel main body 2001 are defined. If the hardware-dependent unit 2002 is constructed in accordance with the rules, the operating system can be operated on various computers.

The hardware-dependent processing according to this rule is separated into a separate object file and mapped to an area 2002 separated from the kernel body. The kernel body 2001 and the hardware dependent unit 2002
Public modules can be called from each other by the same external reference mechanism as in the first embodiment, and apparently function as one kernel.

In such a case, without changing the object file of the kernel itself, the first embodiment and the second embodiment can be implemented by changing the object file for executing the separated hardware-dependent processing. The same effect as that of the embodiment can be obtained.

Specifically, in the processing of the separated object file, it is necessary that physical memory can be allocated, interrupt level management processing can be changed, and I / O resources can be reserved. Further, in this object file, step 1701
Handlers and interrupt tables 107 starting with
And the processor interrupt table register 10
Register to 4. Then, the separated object file is referred to as a common area 203 from the second OS. As described above, the same effects as those of the first embodiment of the present invention can be obtained.

Further, if the hardware-dependent object file is specified to have a module to be executed when the first OS is stopped, the change of the module can detect the stop of the first OS, The same effects as in the second embodiment of the present invention can be obtained.

In this embodiment, there is no need to change the kernel body. This makes it easier to implement than changing the kernel body, which can further limit the parts that need to be changed.

Next, a fourth embodiment of the present invention will be described. In the embodiments described so far, the object files such as the support driver and the hardware-dependent object file are arranged in the common area 203. However, the only modules and data that must be placed in the common area 203 are the interrupt table 107, the interrupt handler starting from step 1701, the OS switching procedure starting from step 1601, and the data structure shown in FIG. In particular, if the entire object file for which the processing of the hardware-dependent unit is performed as in the third embodiment can be referred to from the second OS as the common area 203, the second OS erroneously executes There is a high possibility that the data structure of one OS is accessed, which is a problem.

The fourth embodiment provides a method for showing only a specific section of an object file as a common area 203 to the second OS. In this embodiment, it is necessary that the compiler that generates the object file has a function capable of designating a section in which the instruction code and the data are arranged in the program.

A normal object file has a text section containing an instruction code and a data section containing data as sections. In addition, a section for the common area 203 is added by the function of the compiler. Further, the address range of the common area section is determined with reference to the section data 809 stored in the header part of the object file,
The page table may be constructed so that only that part is shown to the second OS.

A case will be described as an example where an object file including a module that performs hardware-dependent processing is changed. It is not necessary for the second OS to show the part related to the initialization of the changed part, for example, the change of the allocation of the physical memory, the reservation of the I / O resource, and the interrupt level management part. What must be able to be referred from the second OS is
Only the interrupt table 107, the interrupt handler starting from step 1701, the OS switching procedure starting from step 1601, and the data structure shown in FIG. A program is described so that these are arranged in the common area section, and the common area section is generated by the function of the compiler.

FIG. 21 shows the structure of the generated object file. Reference numeral 2100 denotes the generated object file. Object file 2100
2101 to 2104 of the header section describe data of a section included in the object file 2100. Among them, 2103 and 2104 are section data expressing sections newly created for the common area 203. The corresponding section is 210
7 and 2108. Section data 2103 and 21
Sections 2107 and 2108 according to the contents of 04
Of the hardware-dependent object file 2100 from the second OS if the page table of the second OS is configured so that only those areas are mapped to the kernel area of the second OS. Can be hidden.

According to the fourth embodiment, the independence between OSs can be further improved as compared with the above-described embodiments, and a secure computer system with less interference between OSs can be constructed. Become.

Next, a fifth embodiment of the present invention will be described. In the fifth embodiment, the second OS can be introduced by a computer having a multiprocessor configuration.

FIG. 22 is a diagram showing a computer device according to the fifth embodiment of the present invention. Reference numeral 2200 denotes a computer device. The computer 2200 has two processors 2201 and 220
02 and a main storage device 2203. Further, similarly to the first embodiment, it has a storage device 2204 storing a computer activation program.

For the processors 2201 and 2202,
It is assumed that the physical address to which control is transferred differs between when the processor is started and when an interrupt for initialization is received.

The initialization interrupt processing program stored in the storage device 2204 uses the value stored at a predetermined physical address as a physical address and passes control to that address.

Also, devices such as a magnetic disk device 2206, a clock interrupt generation device 2207, and an input / output device 2207 are connected via a bus 2209. The device that generates an interrupt is connected to the interrupt control device 2205, and further connected to the processors 2201 and 2202 via the interrupt bus 2211. Assume that each processor can send an interrupt to another processor.

The interrupt control device 2205 will be described. The interrupt control device 2205 has a function for a multiprocessor configuration. Interrupt control device 220
Reference numeral 5 has a function of designating which processor or processor group is to be notified of an interrupt from each device in addition to the interrupt mask function of the interrupt controller 112 in the first embodiment.

FIG. 23 is a diagram showing a configuration of the interrupt control device 2205. The operations of the selection device 2301 and the interrupt mask register 2302 are the same as in the first embodiment. In addition to them, the interrupt controller 2205
Interrupt delivery table 2310 and interrupt transmission device 2
305.

The interrupt delivery table 2310 records, for each device connected to the interrupt controller 2205, a value 2311 indicating which processor or a group of processors is notified of the interrupt, and an interrupt number 2312 at the time of notification. doing. The interrupt delivery table 2302 can be changed by an I / O instruction and can be set freely.

In the example shown in FIG. 23, interrupts 0 and 1
At 0, interrupt 2 is set to be delivered to CPU1.

The interrupt transmitting device 2305 is connected to the selecting device 2
In response to the signal from 301, the interrupt delivery table 23
10, the interrupt notification destination and the interrupt number are determined. Then, a signal indicating the notification destination and the interrupt number is transmitted to the interrupt bus 2211.

The computer 2200 is configured such that when it starts up, only the processor 2201 starts operating.
The processor 2201 executes a boot program stored in the storage device 2204. The boot program is stored in the magnetic disk device 2206 in the same manner as in the first embodiment.
Is read into the main memory 2203 and executed. The kernel loader creates the parameter table 1100. In the fifth embodiment, data indicating how many processors the computer 2200 has is added to the device list.

After loading the first OS, the first OS is initialized. During the initialization process, the address of the initialization routine for a processor other than the non-boot processor is stored in a predetermined physical address, and an initialization interrupt is sent to the processor 2202. Upon receiving the initialization interrupt, the processor 2202 executes the program stored in the storage device 2204, and passes control to a non-boot processor initialization routine. The non-boot processor initialization routine sets the page table register and the interrupt table register, shifts to the virtual address mode, and continues the initialization processing.

In the fifth embodiment of the present invention, when the device for the second OS is reserved in step 1204 of FIG. 12, the processor also reserves that the processor is dedicated to the second OS.
Here, description will be made assuming that the processor 2202 is reserved.

In the case of a multiprocessor configuration, step 1
In the initialization of the system device in the first OS initialization procedure starting from 201, an initialization interrupt is sent to the non-boot processor. In this case, an initialization interrupt is sent from the processor 2201 to the processor 2202. In the present invention, an initialization interrupt is not sent for a reserved processor. Therefore, even if the kernel is initialized, the processor 2202 has not been operated yet.

In the initialization of the system device in step 1205, the interrupt controller 2205 is also initialized. In the initialization of the interrupt controller 2205, the interrupt delivery table 2310 is referred to by referring to the configuration data 704 of the second OS in the kernel configuration information file 700 so that the interrupt of the device managed by the second OS is sent to the processor 2202. Set.

Further, in the initialization procedure of the second OS starting from step 1401 in FIG. 14, the initialization routine is set to the address of the initialization routine of the second OS, and in step 1407 the processor 2202 is initialized. Send. As a result, the second OS starts running on the processor 2202.

Unlike the first to fourth embodiments, all the interrupts of the devices managed by the second OS are sent by the interrupt controller 2205 to the processor 2202 running the second OS. . Therefore, there is no need to switch the execution OS. The first OS runs on the processor 2201, and the second OS runs on the processor 221.
02 will work. Therefore, step 17
Interrupt processing starting from 01 is not required.

The second OS sets its own interrupt table in the interrupt table register of the processor 2202 and has its own interrupt handler. There is no need to change the interrupt table of the first OS. However, the first O
When S changes the interrupt mask register 2302 of the interrupt control device 2205, it is necessary to make a change so as not to mask the interrupt from the device of the second OS.

In the fifth embodiment, it is possible to construct a computer system with higher performance than in the first to fourth embodiments. In the first to fourth embodiments, the first OS is operable only while the second OS is idle, but in the fifth embodiment, the first OS
In this case, the processor can always operate even though the processor has been robbed, and the second OS can also operate at the same time.

Furthermore, according to the fifth embodiment, the area that must be shared between the first OS and the second OS can be reduced. In the first to fourth embodiments, the interrupt table, the data structure associated with the interrupt handler and the interrupt processing, and the OS switching code have to be placed in the common area 203. In the fifth embodiment, these are all unnecessary, and the possibility that each OS erroneously destroys the other OS can be reduced.

Next, a sixth embodiment of the present invention will be described. While the embodiments described so far are systems in which two OSs are executed simultaneously, the sixth embodiment is a system in which two or more OSs are executed simultaneously.

In the first embodiment, the second OS is controlled to be executed prior to the first OS. However, in the method described here, the execution priority can be set among a plurality of OSs. It is. For example, for interrupts,
Of the interrupt managed by the OS having a lower priority than the priority of the OS is postponed. When an interrupt managed by an OS having a higher priority than the priority of the OS being executed occurs, the execution OS is immediately switched to start interrupt processing.

When the OS being executed calls a module of an OS having a higher priority than itself, the execution OS is immediately executed.
Is switched to execute the module call. In the opposite case, that is, when processing on the side of the OS with a lower priority is necessary, control is performed so that the requested processing is postponed until the OS obtains the execution right.

FIG. 24 is a diagram showing a computer configuration according to the sixth embodiment of the present invention. The computer configuration is the same as in the previous embodiments, but shows a state in which a plurality of OSs are loaded in the main storage device 102. Each operating system can be loaded in the same procedure as the procedure for loading the second OS shown in step 1401.

FIG. 25 is a diagram conceptually showing the relationship between a plurality of OSs. In the first embodiment, two OSs are used.
It is running on one processor.

The common area which is a part of the first OS is the logical space 202, 25 of the other second, third and Nth OSs.
03 and 2504, indicating that they can be shared by all OSs. The mapping of the common area to the logical space of each OS is performed according to the procedure shown in step 1401.

Further, it indicates that each OS has an external device managed by each OS. The second OS is device 1
16 and 117, the third OS is devices 2505 and 2506,
The Nth OS indicates that the device 2507 is managed. The I / O address range and the interrupt number for controlling these devices may be stored in the kernel configuration information file 700 shown in FIG. Although FIG. 7 describes that only the configuration information for the second OS is stored, the configuration information of the third and fourth OSs is also stored. In the initialization procedure from step 1201, the second O
The resources of all the OSs other than the first OS as well as the S are reserved to prohibit the first OS from accessing devices managed by the OSs other than the first OS.

In the procedure starting from step 1201, main memory for the second OS is secured in step 1202. This is a process for securing main memories for a plurality of OSs other than the first OS. Step 1204 is a process for reserving a device managed by the second OS, which is a process for reserving a device resource managed by an OS other than the first OS.

FIG. 26 shows the procedure for initializing the first OS in this embodiment. Steps 2602 and 2604 correspond to steps 1202 and 1204. Step 26
04 reserves device resources of OSs other than the first OS with reference to the kernel configuration information file 700.

At this time, the interrupt management table 15
The processing OS 1521 is also set. The configuration information of each OS describes the priority of the OS in addition to the device resources.

FIG. 27 is a diagram showing a data structure arranged in the common area 203. As compared with the data structure shown in FIG. 15, the interrupt identification table 1520, the OS identification variable 1530, and the delayed interrupt state variable 1540 have the same data structure. OS context table 27
10 has a data structure obtained by extending 1510.

The table 2710 stores data required when switching execution of each OS. Page table setting value 2701 and stack pointer setting 2702
Indicates a page table and a stack pointer address set when a module of another OS is called during execution of a certain OS. Also, the page table storage value 27
03 and the stack pointer storage value 2704 store the page table value and the stack pointer value of the lower priority OS when switching to the higher priority OS is performed.

[0224] The execution state 2705 stores a value indicating whether each OS is operating and waiting for processing. Here, whether the OS is running indicates whether the OS has been started. It does not indicate that it is running at any one moment. The activation process of each OS sets the execution state 2705.

[0225] Also, "waiting for processing" indicates that the OS is not in an idle state. In other words, O
This indicates that S is running and is in a running waiting state. As for the process waiting, it may be described specifically which process is waiting.

The priority 2706 stores the execution priority of each OS. The priority is read and set from the configuration file 700 in step 2605 of the initialization processing procedure of the first OS.

Regarding the procedure for switching the execution OS, the second O
It is assumed that S is being executed. Further, it is assumed that the execution priority of the OS is set to be higher than the first and second and the third is higher than the second. It is assumed that the process on the third OS becomes runnable by the processing of the second OS. In this case, the process on the third OS is scheduled by executing the process activation module in the third OS. Here, since the third OS has a higher priority than the second OS,
The execution OS is immediately switched to execute the third OS module. In the switching process, the current page table address and stack pointer value are stored in the second OS page table storage value 2703 and stack pointer storage 2704 value, and the third OS page table setting value 2701 and stack pointer setting value 2702 are stored. Is set in the page table register and the stack pointer to switch the execution OS.

When the second OS calls the module of the first OS, the calling is postponed because the priority of the first OS is lower than the priority of the second OS. In this case, the call cause is recorded in the execution state 2705, and the first OS
Executes the module call when the second OS obtains the execution right, that is, when the second and third OSs complete the processing.

FIG. 28 is a flowchart showing a procedure for switching the execution OS. Most of the processing from step 2801 is the same as the processing from step 1601 shown in FIG. Although this procedure does not consider the priority of the OS, it compares the priority of the called OS with the priority of the running OS before calling this procedure. May be performed.

The processing starting from step 2801 receives the switching destination OS and the address of the calling module as arguments. In step 2801, the current page table address and stack pointer are stored as the page table storage value 2703 and stack pointer storage value 2704 of the currently executing OS in the OS context table 2710. The currently running OS can be determined by the OS identification variable 1530.

In the next step 2802, the page table setting value 2701 and the stack pointer setting value 2702 of the switching destination OS are obtained from the OS context table 2710, and the page table and stack are switched.

At step 2803, the delay interrupt state is cleared. Delay interrupt status 154 of a device managed by an OS whose priority is equal to or higher than the running OS and lower than the switching destination
Clear 0.

For example, assume that the first OS calls a module of the third OS. In this case, step 2803
Then, the delay interrupt state 1540 of the device managed by the first OS and the second OS is cleared.

In the following step 2804, the execution state 2 of the currently executing OS in the OS context table 2710 is set.
705 is set to "waiting for processing", and in step 2805, the OS
The identification variable is set in the switching destination OS, and the module passed as an argument in step 2806 is called.

The OS at the switching destination returns control to step 2807 when there is no more processing to be performed. Step 2
In step 807, an OS waiting for processing with the highest priority is found by referring to the execution state 2705 and the priority 2706 of each OS in the OS context table.

At step 2808, the OS context selected at step 2807 is recovered from the page table storage value 2703 and stack pointer storage value 2704 of the OS context table 2710.

In the next step 2809, the OS identification variable 1
530 is set to the selected OS.

If the execution state 2705 of the OS context table 2700 records that there is a postponed process, the postponed process is executed (step 2810).

In the subsequent processing, the delayed interrupt is processed. Step 2812 is a delay interrupt state 1540
, It is checked whether an interrupt to be processed by the OS selected in step 2807 has occurred. Which interrupt number the selected OS manages is determined by the processing OS 152 in the interrupt identification table 1520.
Reference is made to FIG.

If it is determined in step 2812 that an interrupt waiting to be processed has occurred, the process proceeds to step 2
Proceed to 813. At step 2813, it is determined that an interrupt to be processed has occurred.
The data structure of the selected OS is set so that the OS can be recognized. In a succeeding step 2814, the interrupt handler 1522 of the interrupt to be processed is called with reference to the interrupt identification table 1520. After the processing of the handler is completed, the execution of the selected OS is resumed according to the recovered context.

If there is no processing waiting interrupt, execution of the selected OS is resumed according to the recovered context.

The interrupt processing will be described. FIG.
9 is a flowchart showing an interrupt processing procedure. The routine for executing the procedure shown in FIG.
Is registered in the interrupt table 400 as the interrupt handler of the. In addition, they are arranged in a common area that can be referenced from all OSs.

The processing procedure will be described. First, in step 2901, the OS that processes the interrupt is determined based on the interrupt factor. The processing OS uses the interrupt identification table 1
520 are recorded in the processing OS 1521 and are determined with reference to this.

OS at the time of occurrence of interrupt and OS for interrupt processing
Are the same (step 2902), the interrupt handler 152 registered in the interrupt identification table 1520
2 is executed (step 2903). Restarts the interrupted process at the end of the handler process.

OS at the time of occurrence of interrupt and OS for interrupt processing
Are different from each other, the priorities of the two OSs are compared (step 2904). If the priority of the OS being executed is higher, the process proceeds to step 2905, where the delayed interrupt state variable 1
540 is set to restart the interrupted processing.

If the priority of the interrupt processing OS is higher than that of the OS being executed, the flow advances to step 2906 to start the interrupt processing.

At step 2906, an interrupt handler address 1522 is obtained from the interrupt identification table 1520. Subsequently, the context at the time of occurrence of the interrupt is saved (step 2907), and the interrupt handler is called (step 2908). The call of the interrupt handler is performed according to the procedure starting from step 2801 in FIG.

Thereafter, when the control returns to the interrupted OS, the context at the time of occurrence of the interrupt is restored (step 2910), and the interrupted process is restarted.

Next, processing modules arranged in the common area 203 will be described. In the common area 203, an OS switching module from step 2801 and an interrupt handler starting from 2901 are arranged. All other OS
Are also arranged in the common area 203. For example, a module that registers the interrupt handler of each OS in the interrupt identification table 1520 and a module that sets the execution state 2705 of the OS context table 2710.

Each OS can process an external interrupt by calling the registration module of the common area 203 and registering the interrupt handler in each initialization process. In addition, when some processing enables processing of another OS with a lower priority than the priority of the OS being executed,
Waiting for execution state 2705, or
A value indicating the cause of the processing wait must be set. Also in this case, the setting is made by calling the execution state setting module in the common area 203.

According to this embodiment, a plurality of OSs can be executed by one processor in addition to the first OS, and an OS specialized for a special function can be combined.
For example, the function of the first OS can be supplemented by combining an OS with excellent real-time properties and an OS that supplements the reliability of the computer. Since each OS is independent, various OSs can be combined, and the function of the first OS can be expanded according to the application. Further, the effects obtained by the embodiments described above are not impaired.

Further, since the priority can be set between the OSs,
It is also possible to set the priority of the real-time OS to be the highest. This makes it possible to effectively use the excellent functions of each OS.

A description will be given of a seventh embodiment of the present invention. This embodiment is an extension of the sixth embodiment. In the seventh embodiment, a control method will be described in which when one of a plurality of operating OSs fails and stops, the other remaining OSs can continue to execute.

When the execution of the OS is stopped, the failure processing module of each OS executes the OS context table 2710.
Must be set to be stopped. This is performed by calling the execution state setting module arranged in the common area 203 in the embodiment.

Each OS has an OS stop notification handler which is called when another OS stops execution, and registers it in the data structure in the common area 203 in the same manner as the interrupt handler.

Next, the processing of the execution state setting module will be described. FIG. 30 is a flowchart showing the processing of this module. Description will be made assuming that the third OS has stopped.

At step 3001, the execution state 2705 of the OS context table 2710 is set.

At step 3002, the set execution state is checked. If it is set to stop OS execution, the process proceeds to step 3003. Otherwise, the processing of the module ends.

In step 3003, the OS stop notification handler of the operating OS having a higher priority than the stopped OS is called. The call is made by switching the OS from step 2801. For the OS with a lower priority, the fact that the OS is waiting for the execution of the OS stop handler is recorded in the execution state 2706. The OS stop notification handler of each OS is
Similarly to the interrupt handler, it is assumed that the OS is registered in the data area located in the common area when the OS is initialized.

In the execution OS switching process, it is necessary to perform a process of checking whether the execution of the switching destination OS has stopped.
This will be described with reference to the flowchart of FIG.

First, before starting the switching process, it is necessary to check whether the switching destination is operating. Step 2801
Before the operation, the execution state 2705 of the OS context table 2710 is checked, and if it is not running, the switching process is terminated.

Furthermore, the next execution OS in step 2807
In the selection, the inactive OS is excluded from the search target of the OS waiting for processing.

Before the execution of the selected OS is resumed, the execution state 2705 of the selected OS is checked. If the execution waiting of the OS stop notification handler is recorded, the OS stop notification handler is executed.

Next, the interrupt processing will be described. This will be described with reference to the flowchart in FIG. After the determination of the interrupt processing OS in step 2901, it is checked whether the processing OS is operating. Here, if it is determined that the operation is not being performed, the interrupt is released and the interrupted process is restarted.

According to the above processing, even if some OSs are stopped due to a failure when a plurality of OSs other than the first OS are operating on one processor at the same time, other OSs are stopped.
S can continue to operate.

Further, since the failure stop of each OS is notified to the other OS, even if the processing is performed in cooperation between the OSs, the failure processing is performed in each OS based on the notification. And the reliability of the computer as a whole can be improved.

In the embodiments described above, the respective OSs may be different from each other or may include the same OS.

[0268]

The present invention is a method for easily introducing a function lacking in the first OS without special hardware support, and the function is completely independent of the first OS. To operate.

According to the present invention, changes to the first OS are limited to the initialization part of the operating system kernel, the device resource reservation, and the interrupt inhibition control part. It becomes possible to operate.

According to the present invention, the operating system for managing each device is determined in advance, and the usable range of the physical memory is determined at the time of initialization. Abolished control by complex software such as virtual machines by preventing operating systems from interfering with each other,
Reduces instruction emulation overhead,
Hardware for speeding up is also unnecessary.

In the prior art, it is possible to add a new function to the kernel as a component of the first OS, but when the first OS is stopped, the added function module also operates. There was no problem that could not. According to the present invention, if a component realizing a new function is configured independently of the first OS, the first OS
Even if is stopped, only the functional module can continue to operate. By incorporating a functional module requiring reliability as the second OS, it becomes possible to realize some kind of recovery processing even when the first OS is stopped.

The first OS can give priority to the second OS by operating only when the second OS is idle or by immediately processing an interrupt of the second OS at any time. Thus, even if the first OS is not suitable for real-time processing, if an OS suitable for real-time processing is introduced as the second OS, real-time processing performance can be maintained while maintaining the characteristics of the first OS. It is possible to construct a computer system that is excellent in terms of.

In the case where the kernel of the first OS is separated into the kernel itself and an object file for executing hardware-dependent processing, the latter object file may be changed without changing the kernel body. Thus, two operating systems can be operated simultaneously. This limits the parts that need to be further changed, so that it is easier to implement than changing the kernel body.

If a section can be freely provided in an object file by a description of a program, an area which must be commonly referred to by the first OS and the second OS by using the section can be specially used. By confining it to a simple section, the independence between OSs can be increased, and O
A secure computer system with little interference between S can be constructed.

According to the present invention, the changes to the first OS are limited to the initialization part of the operating system kernel, the device resource reservation, and the interrupt inhibition control part. It becomes possible to operate.

Even when a plurality of operating systems are operated, the effects described above can be obtained.

In the prior art, it is possible to add a new function to the kernel as a component of the first OS, but when the first OS is stopped, the added function module also operates. There was no problem that could not. According to the present invention, if a component realizing a new function is configured independently of the first OS, the first OS
Even if is stopped, only the functional module can continue to operate. By incorporating functional modules requiring reliability as the second and third OSs, it becomes possible to realize some kind of recovery processing even when the first OS is stopped.

In addition, since a plurality of OSs can be executed by one processor in addition to the first OS, it is possible to combine OSs specialized for special functions. For example,
The function of the first OS can be supplemented by combining an OS with excellent real-time properties and an OS that complements the reliability of the computer. Since each OS is independent, various OSs can be combined, and the function of the first OS can be expanded according to the application without impairing other effects.

Further, since the execution priority can be set among a plurality of OSs, even if the first OS is not suitable for real-time processing, the second OS suitable for real-time processing can be set to the highest priority. For example, it is possible to construct a computer system having excellent real-time processing performance while utilizing the features of the OSs other than the first and second OSs.

When the kernel of the first OS is separated into a kernel body and an object file for executing hardware-dependent processing, the latter object file may be changed without changing the kernel body. Allows multiple operating systems to operate simultaneously. Also, if sections can be freely set in the object file according to the description of the program, the area that needs to be commonly referred to by all OSs is confined to a special section by using the sections. Independence can be enhanced, and a secure computer system with less interference between OSs can be constructed.

[Brief description of the drawings]

FIG. 1 is a diagram showing a computer configuration according to an embodiment of the present invention.

FIG. 2 is a diagram illustrating a computer configuration according to the embodiment of this invention.

FIG. 3 is a diagram showing a configuration of a page table according to the embodiment of the present invention.

FIG. 4 is a diagram illustrating a configuration of an interrupt table according to the embodiment of this invention.

FIG. 5 is a diagram showing a configuration of an interrupt control device according to the embodiment of the present invention.

FIG. 6 is a flowchart illustrating a boot procedure of a computer according to the embodiment of this invention.

FIG. 7 is a diagram illustrating a configuration of a kernel configuration information file of a first OS according to the embodiment of this invention.

FIG. 8 is a diagram illustrating a configuration of an object file according to the embodiment of this invention.

FIG. 9 is a diagram illustrating a configuration of an object file according to the embodiment of this invention.

FIG. 10 is a diagram illustrating a configuration of an object file according to the embodiment of this invention.

FIG. 11 is a diagram illustrating a data structure of a kernel startup parameter table according to the embodiment of this invention.

FIG. 12 is a flowchart illustrating a procedure for initializing a first OS according to the embodiment of this invention.

FIG. 13 is a diagram illustrating a data structure of a device management table of the first OS according to the embodiment of this invention.

FIG. 14 is a flowchart illustrating a startup procedure of a second OS according to the embodiment of this invention.

FIG. 15 is a diagram illustrating a data structure shared by a first OS and a second OS according to the embodiment of this invention.

FIG. 16 is a flowchart illustrating a procedure for switching an execution OS according to the embodiment of this invention.

FIG. 17 is a flowchart illustrating an interrupt processing procedure according to the embodiment of this invention.

FIG. 18 is a diagram illustrating a data structure for interrupt mask processing of a first OS according to the embodiment of this invention.

FIG. 19 is a flowchart illustrating failure stop processing of a first OS according to the second embodiment of this invention.

FIG. 20 is a diagram illustrating a configuration of a kernel area of a first OS and a second OS according to the third embodiment of this invention;

FIG. 21 is a diagram illustrating a configuration of an object file according to a fourth embodiment of this invention.

FIG. 22 is a diagram illustrating a configuration of a computer system according to a fifth embodiment of this invention.

FIG. 23 is a diagram illustrating a configuration of an interrupt control device according to a fifth embodiment of the present invention.

FIG. 24 is a diagram illustrating a computer configuration according to a sixth embodiment of this invention.

FIG. 25 is a diagram illustrating a computer configuration according to a sixth embodiment of this invention.

FIG. 26 is a flowchart illustrating a procedure for initializing a first OS according to a sixth embodiment of the present invention.

FIG. 27 is a diagram illustrating a data structure shared by all OSs according to the sixth embodiment of this invention.

FIG. 28 is a flowchart illustrating a procedure for switching an execution OS according to the sixth embodiment of this invention.

FIG. 29 is a flowchart illustrating an interrupt processing procedure according to the sixth embodiment of this invention.

FIG. 30 is a flowchart illustrating an OS execution state setting procedure according to the sixth embodiment of this invention.

[Description of sign]

100 is a computer, 101 is a processor, 102 is a main memory, 103 is an arithmetic unit, 104 is an interrupt register,
105 is a page table register, 106 is an address converter, 107 is an interrupt table, 108 is a page table, 109 is a bus, 110 is an interrupt signal line, 111
Is a clock generator, 112 is an interrupt controller, 11
3 to 117 are external input / output devices, and 118 is an interrupt bus.

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Hiroshi Ohno 5-2-1 Omikacho, Hitachi City, Ibaraki Prefecture Inside the Omika Plant, Hitachi, Ltd. (72) Inventor Taro Inoue 1099 Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture (72) Inventor Takashi Shibata 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Software Development Division, Hitachi, Ltd.

Claims (20)

[Claims] The present invention relates to a method for controlling a computer, wherein when a first operating system is started, hardware resources used by the other operating system are excluded from the management of the first OS and are given to the other operating system. Emulating privileged instructions executed by each of the operating systems by scheduling the execution of each of the operating systems. And a multi-OS configuration method wherein a plurality of operating systems are simultaneously operated on a single computer without using a device. 2. The multi-OS configuration method according to claim 1, wherein:
A procedure for reserving hardware resources for the second operating system so that they cannot be accessed in the processing after the initialization of the first operating system during the initialization processing of the first operating system; Loading the operating system and launching the second operating system in a virtual address space separate from the first operating system, and sharing a portion of the kernel area of the first operating system with the second operating system And changing the data structure of the first operating system so that the first operating system cannot disable the external interrupt received by the second operating system. Multi-OS configuration wherein the. 3. The multi-OS configuration method according to claim 1, wherein:
The procedure for determining which operating system should perform the interrupt processing based on the interrupt factor when the interrupt is captured, the procedure for calling the module of the second operating system from the first operating system, and the processing of the second operating system are completed A multi-OS configuration method characterized by having a procedure for returning to the first operating system when the two operating systems are operated simultaneously on one computer. 4. A multi-OS configuration method according to claim 1, wherein when the first operating system is stopped due to an unrecoverable failure, a procedure for notifying the second operating system of the stop is provided. Sometimes the procedure to allow interrupts for devices managed by the second operating system, and at the end of processing of the second operating system, determine whether the first operating system is stopped, and if it is stopped A multi-OS, wherein the second operating system can continue to operate even when the first operating system is stopped by having a procedure for executing an interrupt wait.
Configuration method. 5. The multi-OS configuration method according to claim 1, further comprising the step of using a kernel object file in which an instruction code and data that must be shared by both operating systems are locked in a dedicated area. A multi-OS configuration method comprising: a step of finding the area of a first kernel object file at the time of starting an operating system and setting only the area as a shared area, whereby the shared area can be reduced. 6. A multi-OS configuration method according to claim 1, wherein when an interrupt is received from a device managed by the first operating system during execution of the second operating system, the procedure is recorded. Alternatively, when the processing of the device and the second operating system is completed and control is returned to the first operating system, a procedure for starting processing of an interrupt generated during execution of the second operating system; An interrupt from a device managed by the system includes a procedure for immediately switching the operating system and starting interrupt processing even when the first operating system is running, and the first operating system System for the second operating system Only then scheduled to operate at idle, multi-OS configuration method, wherein a second operating system to shorten the response time for interrupt device may occur to manage. 7. The multi-OS configuration method according to claim 1, further comprising a plurality of processors and a device capable of designating notification of an interrupt from an external device to a specific processor or a group of processors. In the computer, a procedure for reserving a processor for the second operating system at the time of initialization of the first operating system, a procedure for starting the second operating system with the processor reserved in the above procedure, and an interrupt from an external device. A multi-OS configuration method comprising a procedure of setting a processor or a group of processors running an operating system that manages each device to notify the processor or the group of processors. 8. A computer control method according to claim 1, wherein when the first operating system is constituted by a plurality of files read at the time of booting and hardware-dependent processing is separated from a file of the kernel itself, 8. The multi-OS configuration method according to claim 1, wherein the hardware-dependent processing file is changed to implement the claims 1 to 7. 9. The multi-OS configuration method according to claim 1, wherein:
During the initialization processing of the first operating system, a procedure for reserving hardware resources for a plurality of other operating systems so that the hardware resources cannot be accessed in the processing after the initialization of the first operating system. Loading a plurality of operating systems and starting another operating system in a virtual address space different from the first operating system; and Having the steps to set to share,
A multi-OS configuration method, wherein a plurality of operating systems can operate on one processor computer. 10. The multi-OS configuration method according to claim 9, wherein the operating system other than the operating system is executed via a module in an area shared with a plurality of other operating systems in the first operating system. A procedure for calling a module of the operating system according to (1). 11. The multi-OS configuration method according to claim 9, wherein when an interrupt is captured, which of the plurality of operating systems being executed is to be subjected to interrupt processing based on an interrupt factor. And a procedure for calling the interrupt processing module of the operating system determined by the above procedure, and a procedure for returning control to the operating system that was being executed when the interrupt occurred, so that a computer having one processor can simultaneously operate a plurality of operating systems. Multi-O characterized by operating
S configuration method. 12. The multi-OS configuration method according to claim 9, wherein when one or more operating systems are stopped due to an unrecoverable failure, the other operating systems are stopped. , A procedure for disabling interrupts managed by a stopped operating system, and a procedure for disabling module calls of the stopped operating system, thereby operating multiple operating systems other than the stopped operating system. A multi-OS configuration method characterized by being able to continue. 13. The multi-OS configuration method according to claim 9, wherein the first operating system uses an object file in which an instruction code and data that must be shared by a plurality of operating systems are locked in a dedicated area. A multi-OS configuration method comprising: a step of finding the area of an object file of a first operating system at the time of starting an operating system other than the system and setting only the area as a shared area, whereby the shared area can be reduced. 14. The multi-OS configuration method according to claim 9, further comprising a step of setting an execution priority among a plurality of operating systems. 15. The multi-OS configuration method according to claim 14, wherein when the running operating system calls a module of another operating system, the priority of the running operating system is changed to the priority of the called operating system. If the priority is lower, the execution operating system is immediately switched to execute the module call, and if the priority of the operating system being executed is higher than the priority of the called operating system, it is determined that there is a module call request. Recording and postponing the call, and performing a module call when the processing of the operating system having a higher priority than that of the called operating system is completed and the called operating system becomes executable. Multi-OS configuration wherein the door. 16. The multi-OS configuration method according to claim 14, wherein when an interrupt is processed by an operating system B having a lower priority than that of the operating system A being executed, the interrupt is recorded and the processing is performed. Postponing procedure or device and operating system A
When the operating system B is executed upon completion of the processing, the procedure for starting the processing of the interrupt generated during the execution of the operating system A is controlled by the operating system having a higher priority than the operating system being executed. Interrupting from the device, immediately switching the execution operating system to start interrupt processing, and shortening the response time to the interrupt generated by the device managed by the operating system with the higher priority. Multi-OS configuration method. 17. The multi-OS configuration method according to claim 16, wherein an interrupt from an external device according to an interrupt managed by each operating system, a priority assigned to each operating system, and an operating system being executed. A method for configuring a multi-OS, comprising means for setting permission and prohibition of an OS. 18. A multi-OS configuration method according to claim 9, further comprising a plurality of processors and a device capable of designating notification of an interrupt from an external device to a specific processor or a group of processors. A step of reserving a processor for a plurality of other operating systems at the time of initialization of the first operating system in the computer, a step of starting the other plurality of operating systems with the processor reserved in the above procedure, and A multi-OS configuration method comprising a step of setting an interrupt to be notified to a processor or a group of processors running an operating system that manages each device. 19. The multi-OS configuration method according to claim 9, wherein a first operating system does not prohibit an external interrupt received by an operating system other than the first operating system from being disabled. Changing the data structure of the operating system. 20. The multi-OS configuration method according to claim 1, wherein a plurality of operating systems are operated by one processor.