JP4026667B2 - Multi-OS configuration method - Google Patents

Description

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

In an ordinary computer, one operating system operates, which manages computer resources such as the processor, memory, and secondary storage of the computer, and implements a resource schedule so that the computer can operate efficiently. There are various types of operating systems. Excellent batch processing and TSS (TimeSharing
There are various types such as those that excel in System) and those that excel in GUI (Graphical User Interface).

  On the other hand, there is a need to simultaneously execute a plurality of operating systems on a single computer. For example, in a large-scale computer, there is a demand to operate an operating system that executes online processing associated with actual work and an operating system for development on a single computer. Alternatively, there is a demand for simultaneously operating an operating system with a good GUI and an operating system with excellent real-time performance.

  However, it is assumed that each operating system independently performs management of 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 one computer, there is a virtual computer system (OS series Vol. 11 VM, Yoshio Okazaki et al., Kyoritsu Publishing Co., Ltd.) realized by a large computer. In the virtual computer system, a virtual computer control program occupies and manages all hardware resources and virtualizes them to configure a virtual computer. The control unit constituting the virtual computer virtualizes physical memory, input / output device, external interrupt, and the like.

  For example, the divided physical memory behaves as if it were a physical memory starting from address 0 for each virtual machine, and the device number for identifying the input / output device is virtualized as well. Furthermore, 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 the control program to be executed on the virtual machine constructed by the control program. However, in the virtual computer system in a large computer, since it is going to completely virtualize and divide a computer resource, the control part which comprises a virtual computer is complicated and is a problem.

  Also, if there is no special hardware support, privileged instructions such as control register settings and I / O instructions issued by the operating system running on the virtual machine must be emulated by the virtual machine control program. Is a problem. In fact, in a large-scale computer in which a virtual computer is mounted, overhead such as a special processor function and hardware such as microcode is added for the virtual computer. The virtual computer system is complicated because it aims to completely virtualize computer resources, and further, a special hardware mechanism is necessary 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 for a plurality of operating systems with one computer. In the microkernel, an operating system server that provides an operating system function to be shown to the user is constructed on the microkernel, and the user uses computer resources via the server. If a server for each operating system is prepared, various operating system environments can be provided to the user.

  However, in the microkernel method, it is necessary to construct a new operating system server in accordance with the microkernel. In many cases, the existing operating system will be changed to run on the microkernel, but the core part of the kernel such as scheduling and memory management will also be changed. However, the change work is complicated and not easy because it extends to the central part of the operating system.

In addition, the operating system server uses a microkernel service, but this is not a normal operating system, which results in overhead and performance degradation.
OS Series Vol.11 VM, Yoshio Okazaki et al., Kyoritsu Publishing Co., Ltd.

  The conventional virtual computer system is based 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 privileged instruction emulation, 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 part, the interrupt management part of the operating system, and adding an interrupt management program. In the present invention, since emulation of privileged instructions is unnecessary, there is no new overhead in the execution of each operating system.

  According to the present invention, a function that complements the first operating system can be easily added, and a highly functional computer system can be constructed. Further, unlike the device driver, since a function that operates completely independently of the first operating system can be incorporated, a highly reliable function that does not depend on the first operating system can be added.

  Further, the method of configuring a plurality of multi-operating system environments by the microkernel method has 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, since the change to the operating system is limited to only the initialization part and the interrupt management part, a multi-operating system environment can be configured easily.

  The present invention reserves computer resources such as a physical memory and an external device required by the second OS in the first OS, and a management program independent from either OS intercepts the external interrupt, Determines which OS's interrupt handler should be started, determines the timing for starting the interrupt handler according to the execution state of the OS, and starts the interrupt handler of each OS based on the determined OS. Operate with a calculator.

  The present invention is a method for easily introducing functions lacking in the first OS without the assistance of special hardware, and further, the functions are operated completely independently of the first OS. enable.

  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 prohibition control part, so that two operating systems can be easily operated simultaneously. Is possible.

  Regarding the overhead generated by the virtual machine method, in the present invention, for each device, an operating system for managing the device is determined in advance, and further, a range that can be used for physical memory is determined at the time of initialization. In order not to interfere with each other, control by complicated software such as a virtual machine is abolished, overhead by instruction emulation is reduced, and hardware for speeding up is 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 stops, the added function module cannot operate. There was a problem. According to the present invention, if a component that realizes a new function is configured independently of the first OS, even if the first OS stops, only the functional module continues. It becomes possible to operate. If a functional module that requires reliability is incorporated as the second OS, even if the first OS stops, some kind of recovery processing can be realized.

  In addition, the first OS can prioritize the second OS by operating only when the second OS is idle, or by immediately processing an interrupt of the second OS. As a result, 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, the real-time processing performance is maintained while taking advantage of the features of the first OS. It is possible to construct a computer system that is excellent in

  In addition, when the kernel of the first OS is separated into the kernel body and the object file that executes hardware-dependent processing, the two object files can be changed by changing the latter object file without changing the kernel body. It becomes possible to operate the operating system simultaneously. As a result, the parts that need to be further changed are limited, and therefore, it becomes easier to implement than changing the kernel body.

  If a section can be freely provided in the object file by describing the program, an area that needs to be commonly referred to by the first OS and the second OS by using the section can be used as a special section. By confining, independence between OSs can be increased, and a safe computer system with less interference between OSs can be constructed.

  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 prohibition control part, so that a plurality of operating systems can be easily operated simultaneously. Is possible.

  Even when a plurality of operating systems are executed, the above-described effects 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 stops, the added function module cannot operate. There was a problem. According to the present invention, if a component that realizes a new function is configured independently of the first OS, even if the first OS stops, only the functional module continues. It becomes possible to operate. If a functional module that requires reliability is incorporated as the second and third OSs, it is possible to realize some kind of recovery processing even when the first OS is stopped.

  Further, since a plurality of OSs can be executed by a single 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 characteristics 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.

  In addition, since the execution priority can be set between a plurality of OSs, even if the first OS is not suitable for real-time processing, if the second OS suitable for real-time processing is set to the highest priority, the first priority can be set. It is possible to construct a computer system with excellent real-time processing performance while taking advantage of the features of OSs other than the first and second OSs.

  In addition, when the kernel of the first OS is separated into the kernel body and the object file that executes hardware-dependent processing, the latter object file can be changed by changing the latter object file without changing the kernel body. It becomes possible to operate the operating system simultaneously. Also, if a section can be freely provided in an object file by describing a program, an area that needs to be commonly referred to by all the OSs by using it can be confined in a special section. Independence can be enhanced, and a safe computer system with less interference between OSs can be constructed.

  Embodiments of the present invention will be described.

  Hereinafter, embodiments of the present invention will be described 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, an interrupt control device 112, a storage device 118 that stores a boot procedure, and an interrupt bus 119. ing.

  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 the 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 numerical interrupt signal according to the request source, and sends the interrupt signal to the processor 101. Further, it is assumed that an interrupt signal from a specific device can be prevented from being notified to the processor 101 by an instruction from the processor 101.

  The processor 101 includes 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 points to the 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 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 control device 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 translation device 106 receives the instruction address requested by the arithmetic unit or the address where the operand is stored, and performs virtual-real address translation based on the contents of the page table 108 pointed to by the page table register 105.

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

  The contents of the main storage device 102 will be briefly described. Currently, two operating systems operate on the computer 101. Each will be referred to as a first operating system and a second operating system. Further, it is assumed that the first OS is set to start when the computer is started, 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 the initialization process at startup. That is, the first OS reserves a physical memory area so that the physical memory area reserved for the second OS cannot be used. FIG. 1 shows a state in which the second OS is loaded in this deprived area.

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

  The first OS has a common area that can be referred to by 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 operates with priority over the first OS. The preferential operation indicates that the first OS can operate only when the second OS is in an idle state. The first OS cannot operate unless the processing of the second OS is completed.

  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 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 so that they can not be accessed with each other except the common area where the interrupt handlers are arranged. This prevents two operating systems from accidentally accessing each other's area and causing a failure.

  Hereinafter, an embodiment of the present invention that realizes the above function will be described.

  FIG. 2 is a diagram conceptually showing the relationship between two operating systems in the embodiment of the present invention. Each operating system maintains 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 memory corresponding to the space 202 of the second OS becomes the area of the second OS of the main memory 102 in FIG.

  A common area 203 is mapped to a part of the virtual space. The real memory corresponding to the common area 203 is an area shown as the common area of the main memory 102 in FIG. The common area 203 is originally a part of the kernel area of the first OS. When the procedure for loading the second OS constructs the address space 202, a page table for the second OS is created so as to map the common area 203 to the address space 202. This procedure will be described later.

  FIG. 2 shows the hardware managed by each operating system.

The first OS indicates that the keyboard 113, the display 114, and the magnetic disk 115 are managed, and the second OS indicates that the input / output devices 116 and 117 are managed. The clock 111 and the interrupt control device 112 are originally hardware managed by the first OS, but indicate that the programs in the common area 203 manage them.

  Next, the configuration of the page table will be described. FIG. 3 shows the configuration of the page table in 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 includes 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 indicates that there is no physical page corresponding to the virtual page 3 because the valid bit is not set. When an access to a virtual page for which the valid bit 301 is not set occurs, the processor generates a page fault.

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

  The address conversion device 106 refers to the contents of the page table indicated by the page table register 105 and converts the virtual address generated by the arithmetic device 103 into a real address. The processor 101 refers to the main storage device 102 by the real address obtained by the conversion.

By switching the page table, an independent space can be constructed, and the first operating system space and the second operating system space shown in FIG. 2 can be constructed. Further, if the common area 203 is set so that the same physical page is mapped to the portion corresponding to the common area of the page tables of both operating systems, the common area can be realized.

  Next, the configuration of the interrupt table will be described. FIG. 4 shows the structure 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 control device 112. When the processor 101 receives 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 that address to perform 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.

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

The interrupt signal line 110 is connected to the selection device 502. When the selection device 502 receives an interrupt signal, it records that there is an unprocessed interrupt until the processor notifies that the interrupt has been received.

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

When the selection device 502 receives an interrupt request from the interrupt signal line 110 and when the contents of the interrupt mask register 501 are rewritten, the selection device 502 displays the unprocessed interrupts recorded by the selection device 502 and the contents of the interrupt mask register 502. Compare to determine whether to notify the processor of an interrupt. Specifically, among the unprocessed interrupts recorded by the selection device 502, the interrupt mask register 501 is set to be interruptible, and the processor is notified in order from the interrupt with the highest priority. For the selected interrupt, the selection device 502 sends a numeric 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 selection device 502 by an input / output command.

  Next, a computer boot procedure according to the embodiment of the present invention will be described.

The first part of the boot procedure is stored in the read-only storage device 118. The storage device 118 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. This procedure carries out detection of the hardware configuration and loading of the program for loading the operating system kernel into the 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 this program when the processor 101 is reset.

The program stored in the storage device 118 is executed by loading the kernel loader of the first OS stored in the magnetic disk device 112 into the main storage device 102. The kernel loader is located at a predetermined position of the magnetic disk device 112, and the program stored in the storage device 118 can easily find it.

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

  This 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 it into the main memory.

  The processing procedure of the kernel loader will be described. First, the main memory list 1101, the load module list 1104, and the 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 memory list 1101 is a data structure indicating the usage status of the main memory device 102. When the kernel loader allocates physical memory in the subsequent processing, the main memory list 1101 is referred to and changed. .

Next, a hardware configuration check (step 602) and hardware configuration data creation (step 603) are performed. In step 602, the hardware checks how the computer 100 is connected. In the subsequent step 603, a device list 1102 that is a data structure related to the hardware configuration is created based on the result of the 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 kernel body file and other device driver files. The configuration information 700 is stored in the magnetic disk 112 with a predetermined file name, and the load program can find it.

The data structure of the kernel configuration information in the embodiment of the present invention is shown in FIG. Reference numeral 700 denotes the contents of a file in which kernel configuration information is recorded. 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, there is an entry whose name is an object file (701), and the data is stored in 702. The secondary OS includes data for the second OS (704).
) Is stored.

Continue to explain the kernel loader procedure. After reading the configuration information 700, all the kernel configuration files stored in the data named object files in the configuration information 700 are read into the main storage device 102 (step 606), and are loaded into the load module list 1104. Add an entry (
Step 607), setting a page table for the kernel (Step 608). Here, object files having file names of kernel, driver1, and driver2 are loaded.

  The addition of the load module list entry and the setting of the kernel page table are performed according to the data stored in the object file loaded in the main memory 102. The object file that constitutes the kernel includes a virtual address that maps the file contents, the size of the file, and the like.

The page table is constructed with reference 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, and the processor is shifted to the virtual address translation mode (step 609).
), Control is passed to the initialization routine of the kernel using the parameter table 1110 comprising the set of the main memory list 1101, the device list 1102, the kernel configuration information table 1103, and the load object list 1104 as parameters (step 610). The kernel entry point is recorded in the data in the kernel file.

  Next, the structure of the object file constituting the kernel will be described. FIG. 8 is a diagram showing the structure of the object file constituting the 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 configuration of the header part will be described. The header map address 801 and the header size 802 describe the storage location in the kernel space of the header portion of the object file 800. The header part is read into the address recorded in the header map address 801.

  The initialization entry 803 records the address of the initialization routine for 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. The section is a continuous data area in the object file, and the mapping of the kernel to the virtual space is determined based on this section. For example, the object file includes a section that stores an execution code and a section that stores 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 describe an external reference table 810 that stores information on public references of other object files that are referred to by the execution code in the object file. The external reference table 810 is included in the header portion 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 in which information of modules and data disclosed by this object file in the execution code of another object file is stored. The public reference table 811 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 for each section included in the object file 800. There are as many section data as the number of sections 804. The configuration 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 constitute a header portion.

  After the header portion, main sections 812 and 813 of each section are stored.

  A configuration of the section data 809 will be described. The section start offset 820 and the section size 821 record the start offset of the section and the size of the section in the object file 800.

  The section is mapped to the kernel virtual space so that it is 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 top of the table 810, the number 901 of external reference information included in this table is stored.

Subsequently, an object file name 902 and an external reference name 903 are stored. The object file name 902 and the external reference name 903 store an offset value to the character string table 905, and the actual character string name 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 the kernel loads the object file into the main memory, the kernel obtains the address of the function or data by referring to the public reference table of the object file including the external reference, and sets it to the external reference address 904. The execution code of the object file is compiled so as to call a function in another object file or refer to data by referring to the address stored in the external function address 904. Execution and data reference are possible.

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 illustrating the structure of the public reference table.

At the top of the table 811, the number of reference names 1001 disclosed to other object modules by the public reference table 811 is recorded. One public reference is described by a public reference name 1002 and a public reference address 1003. The public reference name 1002 stores an offset value to the character string table 1004, and an actual character string name 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 the 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. Since the three lists starting from the parameter table 1100 are arranged in the virtual space of the kernel constructed by the loader, they can be referred to from the kernel.

  The parameter table 1100 holds a pointer to the head of 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, and a load object list 1104, and one table is a kernel configuration information table 1103.

Each will be described.

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

  The main memory block description data records the usage status of a certain continuous main memory 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. A list is configured by a pointer 1114 to the next entry. In FIG. 11, the next entry after 1110 is 1120. By referring to the main memory list 1101, the use state of the physical memory can be known.

  The device list 1102 stores data regarding hardware devices detected by the kernel loader, and is created in step 603. The device list 1103 is a list composed of 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 device described by the device data entry 1150. The device information 1152 stores data specific to the device type. For example, an interrupt number or an I / O address corresponds to this. A list is configured by a pointer 1153 to the next entry.

  A pointer 1103 to the kernel configuration information table 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 object files loaded into the main memory by the kernel loader. The load object list is a list of load object data 1130. The load object data 1130 includes an object file name 1131, an object address 1132, 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 in which the header area of the object file is loaded. A list is configured by a pointer 1133 to the next entry.

  The load object list 1104 is created at the same time when the kernel loader reads an object file constituting the kernel (step 607).

Next, the initialization procedure of the first OS in the embodiment of the present invention will be described. FIG. 12 is a flowchart showing the initialization procedure of the first OS.

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

  In step 1202, a main storage area is secured for the second OS with reference to the main storage list 1101 of the parameter table 1100 passed as a parameter at the time of kernel activation.

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

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

  In the next step 1203, initialization of the data structure inside the kernel is performed.

This initialization includes initialization of a device management table described later.

  In step 1204, a device managed by the second OS is reserved. Reserving here means making 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.

  The device management table will be described. FIG. 13 shows 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 stores, for each interrupt number accepted by the processor 101, a value indicating whether or not the first OS uses the interrupt number. 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 it is not. Entitle the device driver. If it is described as already used, the device cannot be used from the first OS.

  The input / output devices 116 and 117 in FIG. 2 will be described as an example. Assume that I / O devices 116 and 117 request interrupt numbers 4 and 5, respectively. The input / output devices 116 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, the configuration information 704 is referred to, and a value indicating that it is being used is stored in the entries of interrupt numbers 4 and 5 in the interrupt vector management table. Since this process is performed before the first OS starts device management, the first OS cannot access the input / output devices 116 and 117, and the devices 116 and 117 are connected to the second OS. Can be under control.

  The same applies to the I / O address management list 1310. The I / O address management list 1310 is a list made up of entries 1320 representing I / O address ranges. The entry 1320 includes an I / O address range 1321 used by the first OS and a pointer 1322 to the next entry for configuring the list. Similar to 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 the I / O address management list 1310, and does not use it. If there is, an entry is added to this list 1310 to give usage 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. Can reserve an I / O address before the OS starts device management.

By the processing in step 1202, it is possible to construct a space dedicated to the second OS that is completely independent of the first OS. 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. In addition, it is possible to prohibit the introduction of device drivers that use the interrupt numbers and I / O addresses of the devices 116 and 117.

  As an effect of the processing of these two steps, it becomes possible to introduce the second OS into a portion that the first OS is not aware of.

  The subsequent step 1205 or 1207 is the same as the normal initialization process of the operating system. In the initialization of the system device in step 1205, the system device directly managed by the kernel is initialized. The system device is a device that is indispensable for the 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 portion of the object file. Finally, an initial process is created (step 1207).

  Next, the second OS loading procedure in the embodiment of the present invention will be described. FIG. 14 is a flowchart showing the loading procedure of 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 to the virtual space of the first OS (step 1401).

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

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

Regarding the common area 203, an area loaded with a device driver (hereinafter referred to as a support driver) that performs interrupt processing and common data management is referred to as a common area 203. The address at which this device driver is loaded can be known from the load object list 1104. Also,
In the following step 1404, the external reference of the kernel of the second OS is resolved. However, the other object file that can be directly referred to by the second OS is only the function and data arranged in the common area 203, that is, the public reference 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 portion of the object file of the support driver.

  Next, the public reference address of the second OS is written into the external reference address table assigned to the data area of the common area. Since the support driver that is a common area is read as a device driver of the first OS according to the mechanism of the first OS, it cannot be linked to the public reference of the second OS.

  Here, 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 is described by referring to this table, calling the public function of the kernel of the second OS, and referring to the public data. Then, when the second OS is loaded, the public reference address of the support driver is written in the external address column of this table.

  This completes the setting of the second OS area and cancels the mapping of the physical memory area for the second OS mapped to the kernel area of the first OS (step 1406).

Next, the context of the second OS in the OS context table 1510 and the OS identification variable 1530 are set (step 1407). The OS context is a data structure that is referred to when the execution operating system is switched, and includes a page table address value and an initial value of the stack pointer. Here, the page table address that maps the second OS is set as the page table register value, and the kernel stack initial address 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 of operating system space. The switching of the operating system will be described with reference to another flowchart. 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 copied to the handler column 1522 of the interrupt identification table 1520, and the interrupt table register value is changed to the support driver. Change to the interrupt table address assigned to. This is performed by changing the interrupt table register 104 of the processor 101.

  The reason why the interrupt table is changed to a 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 an interrupt occurs. Interrupt handlers registered in the interrupt table are also placed in the support driver. In step 1403, the support driver area is also mapped to the virtual space of the second OS to form 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 interrupt management information of the first OS is also changed. Specifically, the data structure related to the interrupt inhibition level is changed, which will be described later.

  A 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 in 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 holds data necessary for switching between the first OS and the second OS.

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 a certain point during execution of the first OS, and control may be returned to the first OS when the execution of the second OS is completed.

  Therefore, only one set of contexts must be stored for each. As 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 saved, the control is performed by the first OS after the execution of the second OS is completed. Can be restored.

  Also, when switching control from the first OS to the second OS, the second OS is not operating. Accordingly, the second OS context may be a fixed value for both the page table address and the stack pointer. The page table register value 1513 and the stack pointer value 1514 of the second OS are set when the second OS is loaded (step 1407).

Reference numeral 1520 denotes an interrupt identification table. In the interrupt identification table 1520, for each interrupt number of an external interrupt, a value 1521 indicating which operating system handles the interrupt and an interrupt handler address 1522 are recorded. When an external interrupt occurs, the interrupt handler in the common area 203 captures the interrupt, refers to the processing OS 1521 of the interrupt identification table 1520, determines which OS is to be processed, and controls the address of the handler 1522. hand over. Details of the interrupt processing will be described later.

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

Reference numeral 1540 denotes a delayed interrupt state 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 of the interrupt has occurred. The OS switching procedure checks this variable 1540 when the execution of the second OS is completed, and determines whether to start interrupt processing (step 1608).

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

  The procedure shown in FIG. 16 receives the address of the module of the second OS to be executed after switching to the second OS and an argument to be passed to the module as arguments. 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 saved as the first OS context in the OS context table 1510. In step 1601, the current stack pointer value is saved in 1512 and the current page table register 105 value is saved in 1511.

  Other register contexts need not be stored in the OS context table 1510. If necessary, it can be saved in the stack of the first OS.

  After saving the stack pointer and the page table register value, in step 1602, the page table address for mapping the second OS to the virtual space is set in the page table register 105. This is recorded in 1513 of the OS 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 delayed interrupt state variable 1540 indicating the interrupt state of the first OS is cleared. The status variable 1540 is a variable for recording an occurrence status of an interrupt from a device managed by the first OS that occurs during execution of the second OS. Clear this before running the second OS.

Then, the OS identification variable 1530 indicated by the currently executing OS is rewritten to a value indicating the second OS (step 1604). Since the stack pointer, page table register 105, and OS identification variable 1530 must always have consistent values, steps 1601 and 1604 up to this point must be executed with all external interrupts disabled. I must.

  In subsequent 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 executed, that is, when the second OS is in an idle state. Therefore, when the processing of the second OS is completed, control returns to step 1606.

  In step 1606, the page table register value 1511 and the stack pointer value 1512 stored in the OS context table 15100 in step 1601 are restored. In the following step 1607, the OS identification variable 1530 is changed to a value indicating that the first OS is being executed. 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 that occurs during execution of the second OS is processed. First, in step 1608, the delayed interrupt state variable 1540 is inspected to determine whether an interrupt has occurred. If not, the OS switching procedure ends and returns to the caller.

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

  An interrupt process in the embodiment of the present invention will be described. FIG. 17 is a flowchart showing the interrupt processing procedure of this 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 the common area 203 that can be referred to by both operating systems.

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

  If the interrupt is a first OS device interrupt, step 1702 is executed. In step 1702, the OS executed when the interrupt occurs is determined. This determination is performed with reference to the OS identification variable 1530. If the OS being executed is the first OS, the process proceeds to step 1703, and if it 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 while the first OS is being executed. In step 1703, the context is set so that there is no processing starting from step 1701, and the interrupt handler of the first OS seems to be directly controlled by the processor 101. Here, the context indicates the contents of the stack and the contents of the register. Then, control is passed to the interrupt handler of the first OS. The address of the interrupt handler of the first OS is stored in the handler column 1522 of the interrupt identification table 1520. 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 does not return to the procedure starting from step 1701, and the first OS continues processing.

  If the device managed by the first OS generates an interrupt while executing the second OS, step 1704 is executed. In step 1704, the interrupt number of the device that generated the interrupt is recorded in the delayed interrupt status variable 1540. The interrupt handler process ends here. The interrupt process in this case is executed when the execution 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, the process proceeds to step 1705 to check which OS is being executed. Again, the OS being executed is determined by the OS identification variable 1530. If the first OS is being executed, the process proceeds to step 1706, and 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 execution of the second OS, step 1711 is executed. Step 1711 starts 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 interrupt handler processing of the second OS is finished and the control is returned, this interrupt handler is also finished, the context at the time of interruption is restored, and the control is restored.

  If an external interrupt of a device managed by the second OS occurs during execution of the first OS, step 1706 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. The context here indicates the contents of the stack and the contents of the registers necessary to recover the state when interrupted when returning to the first OS after completion of the interrupt processing. This context is stored in the kernel stack of the first OS.

Subsequently, the execution OS is switched and the interrupt processing of the second OS is started (
Steps 1707, 1708). This is performed according to the procedure starting from step 1601.

When the processing of the second OS is completed, switching to the first OS is executed (step 1709), the context at the time of interruption is recovered (step 1710), and the processing of the first OS is resumed. The processing in step 1709 need not necessarily be executed in the same module as the processing starting from step 1701. The processing returns to this module by switching to the first OS.

  The processing of clock interrupt shared by the two operating systems will be described. A clock interrupt is captured by an interrupt handler in the common area. In this interrupt handler, first, an interrupt handler for clock interrupt of the second OS is executed. The interrupt handler of the second OS is stored in the handler 2 column 1523. 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 stored in the handler column 1522.

  Next, the interrupt control part 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.

  Assume that the first OS controls interrupts according to the interrupt prohibition level. The interrupt prohibition level is a mechanism necessary for realizing 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 prohibition 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 at all about the second OS, there is a possibility that when the first OS changes the interrupt inhibition level, the interrupt of the device of the second OS is masked. In order to prevent this, the interrupt control part of the first OS is changed.

  FIG. 18 shows a data structure managed by the first OS that realizes the interrupt prohibition level. Reference numeral 1800 denotes an interrupt prohibition level table. Each interrupt level is represented by a numerical value and indicates the number of external interrupts to be masked for each interrupt disable level. In the table 1800, a check mark indicates that an interrupt is set to be masked. For example, the interrupt prohibition table 1800 indicates that no interrupt is masked at interrupt prohibition level 0. Further, in the interrupt prohibition level 3, the interrupt control device 112 masks interrupts of interrupt numbers 3 to 5. At interrupt inhibition level 5, all interrupts are masked by the interrupt controller 112.

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

  In this example, interrupt numbers 4 and 5 are interrupts processed by the second OS. Accordingly, the columns of interrupt numbers 4 and 5 (all of 1801 and 1802) of all interrupt prohibition levels in the interrupt prohibition level table 1800 are cleared.

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

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

  According to the present invention, when a change is made to the first OS and two operating systems are operated simultaneously, the changed part is limited to the initialization part of the operating system kernel, the device resource reservation, and the interrupt prohibition control part. Therefore, it becomes possible to easily operate two operating systems.

  The virtual computer method requires emulation of privileged instructions in order to virtualize physical memory and I / O channels. However, if this is realized by software, there is a problem in that overhead increases. Virtual computer systems often have special hardware to reduce this overhead. However, in the present invention, for each device, the operating system that manages the device is determined in advance, and further, by determining the range that can be used for the physical memory at the time of initialization, the operating systems do not interfere with each other, Control by complicated software such as a virtual machine has been abolished, and hardware for speeding up is not necessary.

  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 it is a component of the first OS, there is a problem that the component can operate only under the management of the first OS. In other words, when the first OS is stopped due to a failure, the added function module cannot be operated.

  According to the present invention, a component that realizes a new function can be configured independently of the first OS, and even if the first OS stops, only the function module continues. It becomes possible to operate. This embodiment will be described later. If a functional module that requires reliability is incorporated as the second OS, even if the first OS stops, it is possible to realize some kind of recovery processing. Thus, the present invention is an invention that can be a means for realizing high reliability of a computer system.

In this embodiment, the second OS has been described as executing processing in preference to the first OS. The first OS gives priority to the second OS by being able to operate only when the second OS is idle, and by processing interrupts of the second OS immediately at any time. As a result, 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, the real-time processing performance is maintained while taking advantage of the features of the first OS. It is possible to construct a computer system that is excellent in For example, if the first OS has an excellent GUI (Graphical User Interface) but lacks real-time processing performance, the second OS is the operating system for real-time processing that operates with priority over the first OS. By introducing it, it is possible to construct a computer system that is excellent in GUI and excellent in real-time processing.

  As described above, the present invention is a method for easily introducing a function lacking in the first OS without assistance of special hardware, and the function is completely independent of the first OS. To make it work.

  Next, a second embodiment of the present invention will be described. The second embodiment is an extension of the embodiment described so far. In this embodiment, it is possible to introduce a second OS that continues to operate even if the first OS stops due to a failure.

  In addition to the first embodiment, the first OS execution state variable 1550 is placed in the common area.

The variable 1550 stores a value indicating whether the first OS is operating normally or not. This variable 1550 is initialized to a value indicating normal operation in the process when loading the second OS.

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

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

  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 the second OS module is executed 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 is a value indicating that the first OS is stopped, the process of step 1606 and the subsequent steps is not executed, and an interrupt wait is executed.

  With the above data structure and procedure, even if the first OS is stopped, it is possible to continue the execution of the second OS. In this embodiment, the stop processing module of the first OS is changed. However, the module executed in the stop processing process 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 so far, the simultaneous execution of two OSs and the like have been realized by changing the kernel body. In the third embodiment, the functions of the above-described 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 body and configured as a separate object file. For example, there are cases where the interrupt control device 112 differs from computer to computer, or the configuration of the bus 109 is different and the I / O address space varies from computer to computer.

  FIG. 20 shows the kernel in the case where the code and data for absorbing the difference in hardware such as an operating system, that is, an interrupt control device and a bus, are in an object file separated from the kernel body. It is the figure which showed the mode of the area | region.

  The kernel area 2000 includes modules executed in the kernel mode of the processor 101 and data structures managed by the operating system. The kernel main body 2001 has code and data for performing hardware-independent processing such as memory management, process scheduling, and file system. Between the kernel main body 2001 and the hardware dependent unit 2002, a rule regarding the modules that the hardware dependent unit 2002 must provide and the modules provided by the kernel main body 2001 are defined. If the hardware-dependent unit 2002 is constructed in accordance with this rule, this operating system can be operated on various computers.

  The hardware-dependent processing according to this rule is separated into separate object files and mapped to an area 2002 separated from the kernel body. The kernel main body 2001 and the hardware dependent unit 2002 can call each other's public modules by the same external reference mechanism as in the first embodiment, and apparently function as one kernel.

In such a case, it is the same as the first embodiment and the second embodiment by changing the object file that performs the separated hardware-dependent processing without changing the object file of the kernel body. It is possible to obtain the effect.

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, an interrupt handler starting from step 1701 and the interrupt table 107 are arranged in this object file and registered in the interrupt table register 104 of the processor. Then, the separated object file can be referred to from the second OS as the common area 203. As described above, the same effects as those of the first embodiment of the present invention can be obtained.

  Furthermore, if the hardware-dependent object file is defined to have a module that is executed when the first OS is stopped, the stop of the first OS can be detected by changing the module. The same effect as in the second embodiment can be obtained.

In this embodiment, there is no need to change the kernel body. As a result, the parts that must be changed can be further limited, and can be implemented more easily than changing the kernel body.

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, as in the third embodiment, if the entire object file that performs the processing of the hardware-dependent unit can be referred to from the second OS as the common area 203, the second OS mistakenly becomes the first OS. This increases the possibility of accessing the data structure of one OS.

  In the fourth embodiment, a method is provided in which only a specific section of an object file is shown as a common area 203 to the second OS. In this embodiment, a compiler that generates an object file needs to have a function that can specify a section in which an instruction code and data are arranged on a program.

  A normal object file has a text section including an instruction code as a section and a data section including data. In addition to this, a section for the common area 203 is added by the function of the compiler. Furthermore, it is only necessary to determine the address range of the common area section with reference to the section data 809 stored in the header portion of the object file, and to construct the page table so that only the portion is shown to the second OS.

  A case where an object file including a module that performs hardware-dependent processing is changed will be described as an example. It is not necessary to show the second OS the part related to the initialization of the changed part, for example, the allocation of the physical memory, the reservation of the I / O resource, and the change of the interrupt level management part. 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. 15 need to be referenced from the second OS. 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 a generated object file. The header part 2101 to 2104 of the object file 2100 describes section data included in the object file 2100. Of these, 2103 and 2104 are section data representing sections newly created for the common area 203. The corresponding sections are 2107 and 2108. If the addresses of the sections 2107 and 2108 are obtained according to the contents of the section data 2103 and 2104, and the page table of the second OS is configured so that only those areas are mapped to the kernel area of the second OS, the hardware dependence Other parts of the object file 2100 can be hidden from the second OS.

  According to the fourth embodiment, the independence between OSs can be further increased compared to the embodiments described so far, and a safe computer system with less interference between OSs can be constructed.

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

FIG. 22 is a diagram illustrating a computer apparatus according to the fifth embodiment of this invention. Reference numeral 2200 denotes a computer apparatus. A computer 2200 includes two processors 2201 and 2202.
And a main memory 2203. Further, as in the first embodiment, the storage device 2204 that stores the computer activation program is provided.

  With respect to the processors 2201 and 2202, the physical addresses to which control is transferred differ when the processors are activated and when an interrupt for initialization is received.

  The initialization interrupt processing program stored in the storage device 2204 uses the value stored in 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. A device that generates an interrupt is connected to an interrupt control device 2205 and further connected to processors 2201 and 2202 via an interrupt bus 2211. Assume that each processor can send an interrupt to other processors.

The interrupt control device 2205 will be described. The interrupt control device 2205 has a function for a multiprocessor configuration. In addition to the interrupt mask function of the interrupt control device 112 in the first embodiment, the interrupt control device 2205 has a function to specify which processor or processor group is notified of an interrupt from each device. ing.

FIG. 23 is a diagram illustrating a configuration of the interrupt control device 2205. The functions of the selection device 2301 and the interrupt mask register 2302 are the same as those in the first embodiment. In addition to these, the interrupt control device 2205 has an interrupt delivery table 2310 and an interrupt transmission device 2305.

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

  In the example of FIG. 23, interrupts 0 and 1 are set to be delivered to CPU 0 and interrupt 2 is set to be delivered to CPU 1.

  The interrupt transmission device 2305 receives a signal from the selection device 2301 and refers to the interrupt delivery table 2310 to determine an interrupt notification destination and an interrupt number.

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 only the processor 2201 starts operation when activated, and the processor 2201 executes the activation program stored in the storage device 2204. As in the case of the first embodiment, the boot program reads the kernel loader stored in the magnetic disk device 2206 into the main memory 2203 and executes it. The kernel loader creates a 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 initialization process of the first OS is executed. In the initialization process, the address of an 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. When the processor 2202 receives the initialization interrupt, the processor 2202 executes the program stored in the storage device 2204, and control is passed to the 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 process.

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

  In the case of the multiprocessor configuration, an initialization interrupt is sent to the non-boot processor at the initialization of the system device in the first OS initialization procedure starting from step 1201. 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 is not yet operating.

  In the initialization of the system device in step 1205, the interrupt control device 2205 is also initialized. In the initialization of the interrupt control device 2205, the interrupt delivery table 2310 is referenced so that an interrupt of a device managed by the second OS is sent to the processor 2202 with reference to the configuration data 704 of the second OS in the kernel configuration information file 700. 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 an initialization interrupt is sent to the processor 2202 in step 1407. As a result, the second OS starts running on the processor 2202.

  Unlike the first to fourth embodiments, all interrupts of devices managed by the second OS are sent by the interrupt control device 2205 to the processor 2202 in which the second OS is operating. For this reason, there is no need to switch the execution OS. The first OS operates on the processor 2201, and the second OS operates on the processor 2202. Therefore, the interrupt process starting from step 1701 is also unnecessary.

  The second OS can set its own interrupt table in the interrupt table register of the processor 2202 and have its own interrupt handler. There is no need to change the interrupt table of the first OS. However, when the first OS 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 better performance than in the first to fourth embodiments. In the first to fourth embodiments, the first OS can operate only while the second OS is idle. In the fifth embodiment, the first OS Although it is stolen, it can always operate, and at the same time, the second OS can also operate.

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

  Next, a sixth embodiment of the present invention will be described. While the embodiment described so far is a method of executing two OSs simultaneously, the sixth embodiment is a method of simultaneously executing two or more OSs.

  In the first embodiment, control is performed such that the second OS is executed with priority over the first OS. However, in the method described here, an execution priority can be set between a plurality of OSs. For example, for interrupts, interrupt processing managed by an OS having a lower priority than the priority of the OS being executed is postponed. When an interrupt managed by an OS having a higher priority than the priority of the OS being executed is generated, the execution OS is immediately switched to start interrupt processing.

  Further, when the OS being executed calls an OS module having a higher priority than itself, the execution OS is immediately switched to execute the module call. In the opposite case, that is, when processing on the OS side having a low priority is required, 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 this 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, there are two OSs, but here, a plurality of OSs other than the first OS are operating on one processor.

  The common area that is a part of the first OS is mapped to the logical spaces 202, 2503, and 2504 of the other second, third, and Nth OSs, and can be used in common 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.

  Furthermore, each OS has an external device managed by each OS.

The second OS indicates that the devices 116 and 117 are managed, the third OS is that the devices 2505 and 2506 are managed, and the Nth OS is that the device 2507 is managed. The I / O address range and interrupt number for controlling these devices may be stored in the kernel configuration information file 700 shown in FIG. Although it is described in FIG. 7 that only the configuration information for the second OS is stored, the configuration information of the third and fourth OSs is stored in addition. In the initialization procedure from step 1201, not only the second OS but also all OS resources other than the first OS are reserved, and the first OS accesses devices managed by the OS other than the first OS. Is prohibited.

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

  The initialization procedure of the first OS in this embodiment is shown in FIG. Steps 2602 and 2604 correspond to steps 1202 and 1204. Step 2604 reserves device resources of OSs other than the first OS with reference to the kernel configuration information file 700.

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

FIG. 27 is a diagram illustrating a data structure arranged in the common area 203. Compared to 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. The OS context table 2710 has a data structure obtained by extending 1510.

  A table 2710 stores data necessary for switching execution of each OS. The page table setting value 2701 and the stack pointer setting 2702 indicate the address of the page table and the stack pointer that are set when calling a module of another OS while executing a certain OS. Further, the page table storage value 2703 and the stack pointer storage value 2704 store the page table value and the stack pointer value of the OS with the lower priority when switching to the OS with higher priority is performed. .

  The execution state 2705 stores a value indicating whether each OS is operating and waiting for processing. Here, whether it is operating indicates whether the OS is activated. It does not indicate that it is running at a certain moment. Each OS activation process sets an execution state 2705.

  Also, waiting for processing indicates that the OS is not idle. In other words, it indicates that the OS with high priority is running and is in a waiting state for traveling. In the process waiting state, it may be specifically described which process is waiting.

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

  The execution OS switching procedure will be described on the assumption that the second OS is being executed.

Further, it is assumed that the execution priority of the OS is set to be higher than that of the first, and that of the third is higher than that of the second. It is assumed that the process on the third OS can be run by the processing of the second OS. In this case, a process activation module in the third OS is executed to schedule a process on 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 module of the third OS. In the switching process, the current page table address and stack pointer value are stored in the page table saved value 2703 and stack pointer saved 2704 value of the second OS, and the page table set value 2701 and stack pointer set value 2702 of the third OS. 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 call is postponed because the priority of the first OS is lower than the priority of the second OS. In this case, the call factor is recorded in the execution state 2705, and the module call is performed when the first OS obtains the execution right, that is, when the second and third OSs complete the processing.

  FIG. 28 is a flowchart showing the execution OS switching procedure. Most of the processing from step 2801 is the same as the processing from step 1601 shown in FIG. This procedure does not consider the priority of the OS, but before calling this procedure, the priority of the called OS is compared with the priority of the running OS. It is sufficient to perform the process.

  The process starting from step 2801 receives the address of the switching destination OS and the calling module as arguments. In step 2801, the current page table address and stack pointer are stored in the page table storage value 2703 and stack pointer storage value 2704 of the OS currently being executed in the OS context table 2710. The OS currently being executed 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 acquired from the OS context table 2710, and the switching process between the page table and the stack is performed.

  In step 2803, the delayed interrupt state is cleared. The delayed interrupt state 1540 of the device managed by the OS with the priority higher than the OS being executed and less than the switching destination is cleared.

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

  In the subsequent step 2804, the execution state 2705 of the OS currently being executed in the OS context table 2710 is set to waiting for processing, the OS identification variable is set to the switching destination OS in step 2805, and the module passed as an argument in step 2806 Call.

  The switching-destination OS returns control to step 2807 when there is no more processing to be performed. In step 2807, the execution status 2705 and priority 2706 of each OS in the OS context table is referred to, and the OS waiting for processing with the highest priority is found.

  In step 2808, the OS context selected in step 2807 is restored from the page table storage value 2703 and the stack pointer storage value 2704 of the OS context table 2710.

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

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

  In subsequent processing, the delayed interrupt is processed. Step 2812 refers to the delayed interrupt state 1540 and checks whether an interrupt to be processed by the OS selected in Step 2807 has occurred. Which interrupt number is managed by the selected OS can be determined by referring to the processing OS 1521 of the interrupt identification table 1520.

  As a result of the inspection in step 2812, if it is determined that an interrupt waiting for processing has occurred, the process proceeds to step 2813. In step 2813, the data structure of the selected OS is set so that the selected OS can recognize that an interrupt to be processed has occurred. In the subsequent step 2814, the interrupt identification table 1520 is referred to and the interrupt handler 1522 of the interrupt to be processed is called. After the handler processing is completed, 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 process will be described. FIG. 29 is a flowchart showing an interrupt processing procedure. A routine for executing the procedure shown in FIG. 29 is registered in the interrupt table 400 as an interrupt handler of the processor 103. Further, it is arranged in a common area that can be referred to by all OSs.

  A processing procedure will be described. First, in step 2901, an OS for processing an interrupt is determined based on an interrupt factor. The processing OS is recorded in the processing OS 1521 of the interrupt identification table 1520 and is determined with reference to this.

If the OS at the time of interrupt occurrence is the same as the interrupt processing OS (step 2902)
Then, the interrupt handler 1522 registered in the interrupt identification table 1520 is executed (step 2903). Resumes the interrupted process at the end of the handler process.

If the OS at the time of interrupt occurrence is different from the interrupt processing OS, 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 1540 is set, and the interrupted process is resumed.

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

In step 2906, the interrupt handler address 1522 is acquired 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 by the procedure starting from step 2801 in FIG.

  After that, when control returns to the interrupted OS, the context at the time of occurrence of the interrupt is recovered (step 2910), and the interrupted process is resumed.

  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. Modules called from all other OSs are also arranged in the common area 203. For example, a module for registering an interrupt handler of each OS in the interrupt identification table 1520 or a module for setting an execution state 2705 of the OS context table 2710.

Each OS calls the registration module in the common area 203 and registers an interrupt handler in each initialization process, thereby enabling external interrupt processing. Further, when processing of another OS having a lower priority than the priority of the OS being executed becomes possible due to some processing, the execution state 2705 is waiting for processing or a value indicating the cause of processing waiting. Must be set. In this case as well, the setting is made by calling the execution state setting module in the common area 203.

  According to the present embodiment, a plurality of OSs can be executed by one processor in addition to the first OS, and OSs specialized for special functions can be combined. For example, the function of the first OS can be supplemented by combining an OS with excellent real-time characteristics 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. Furthermore, the effects obtained by the embodiments described so far are not impaired.

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

  A seventh embodiment of the present invention will be described. This embodiment is an extension of the sixth embodiment. In the seventh embodiment, a control method is shown in which, when a certain OS among a plurality of operating systems is stopped due to a failure, other remaining OSs can continue execution.

  When the failure processing module of each OS stops the execution of the OS, the execution state 2705 of the OS context table 2710 must be set as being stopped. This is performed by calling the execution state setting module arranged in the common area 203 in the above embodiment.

  Each OS has an OS stop notification handler that is called when the other OS stops execution, and registers it in the data structure in the common area 203 like the interrupt handler.

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

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

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

  In step 3003, an OS stop notification handler of an operating OS having a higher priority than the stopped OS is called. Calling is performed by OS switching from step 2801. For an OS with a low priority, it records in the execution state 2706 that it is waiting for OS stop handler execution. Further, the OS stop notification handler of each OS is registered in the data area arranged in the common area at the time of initialization of each OS, similarly to the interrupt handler.

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

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

  Further, in the selection of the next execution OS in step 2807, the OS that is not operating is excluded from the search targets of the OS waiting for processing.

  Before resuming execution of the selected OS, the execution state 2705 of the selected OS is inspected, and if execution waiting for the OS stop notification handler is recorded, the OS stop notification handler is executed.

  Next, interrupt processing will be described. This will be described with reference to the flowchart of FIG. After determining the interrupt processing OS in step 2901, it is checked whether the processing OS is operating. If it is determined that it is not in operation, the interrupt is released and the interrupted process is resumed.

  With the above processing, when a plurality of OSs other than the first OS are operating simultaneously on one processor, even if some OSs stop due to a failure, the other remaining OSs can continue to operate. It becomes possible.

  In addition, since the failure stop of each OS is notified to the other OS, even when the processing is performed in cooperation between the OSs, it is possible to perform the failure processing in each OS based on the notification. Yes, the reliability of the entire computer can be improved.

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

It is a figure which shows the computer structure of embodiment of this invention. It is a figure which shows the computer structure of embodiment of this invention. It is a figure which shows the structure of the page table of embodiment of this invention. It is a figure which shows the structure of the interruption table of embodiment of this invention. It is a figure which shows the structure of the interrupt control apparatus of embodiment of this invention. It is a flowchart which shows the boot procedure of the computer of embodiment of this invention. It is a figure which shows the structure of the kernel configuration information file of 1st OS of embodiment of this invention. It is a figure which shows the structure of the object file of embodiment of this invention. It is a figure which shows the structure of the object file of embodiment of this invention. It is a figure which shows the structure of the object file of embodiment of this invention. It is a figure which shows the data structure of the kernel starting parameter table of embodiment of this invention. It is a flowchart which shows the initialization procedure of 1st OS of embodiment of this invention. It is a figure which shows the data structure of the device management table of 1st OS of embodiment of this invention. It is a flowchart which shows the starting procedure of 2nd OS of embodiment of this invention. It is a figure which shows the data structure which 1st OS and 2nd OS share of embodiment of this invention. It is a flowchart which shows the switching procedure of execution OS of embodiment of this invention. It is a flowchart which shows the interruption processing procedure of embodiment of this invention. It is a figure which shows the data structure for the interrupt mask process of 1st OS of embodiment of this invention. It is a flowchart which shows the failure stop process of the 1st OS of the 2nd Embodiment of this invention. It is a figure which shows the structure of the kernel area | region of 1st OS and 2nd OS of the 3rd Embodiment of this invention. It is a figure which shows the structure of the object file of the 4th Embodiment of this invention. It is a figure which shows the structure of the computer system of the 5th Embodiment of this invention. It is a figure which shows the structure of the interrupt control apparatus of the 5th Embodiment of this invention. It is a figure which shows the computer structure of the 6th Embodiment of this invention. It is a figure which shows the computer structure of the 6th Embodiment of this invention. It is a flowchart which shows the initialization procedure of 1st OS of the 6th Embodiment of this invention. It is a figure which shows the data structure which all the OS of the 6th Embodiment of this invention shares. It is a flowchart which shows the switching procedure of execution OS of the 6th Embodiment of this invention. It is a flowchart which shows the interrupt processing procedure of the 6th Embodiment of this invention. It is a flowchart which shows the OS execution state setting procedure of the 6th Embodiment of this invention.

Explanation of symbols

100 is a computer, 101 is a processor, 102 is a main storage device, 103 is an arithmetic unit, 104 is an interrupt register, 105 is a page table register, 106 is an address translation device, 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, 113 to 117 are external input / output devices, and 118 is an interrupt bus.

Claims (3)

  In a multi-OS control method of a computer system that operates a plurality of operating systems on a computer,
  The computer system includes:
  A processor;
  Multiple hardware devices,
  A first operating system (hereinafter, “first OS”) executed by the processor and assigned to a first hardware resource of the hardware device;
  A second operating system (hereinafter referred to as “second OS”) executed by the processor, allocated to a second hardware resource of the hardware device, and executed independently of the first OS;
  An area mapped to the virtual space of the first OS and the second OS, and a storage device having a common area commonly used by the first OS and the second OS,
  The means for starting up the first OS sets the storage area for the second OS before the first OS starts managing free memory of the storage device during the initialization process of the first OS. Before the first OS starts managing devices, the device management table managed by the first OS cannot use interrupts from the second hardware resource from the first OS. Register to do,
  A multi-OS control method characterized by that.   The multi-OS control method according to claim 1,
  A support driver that is executed by the processor and performs interrupt processing;
  The support driver is loaded into the common area,
  When an external interrupt occurs, the support driver refers to the processing OS in the interrupt identification table and determines whether to process the first OS or the second OS based on the interrupt factor.
  A multi-OS control method characterized by that.   The multi-OS control method according to claim 1 or 2,
  The means for starting the second OS loads the second OS into the reserved storage area, and an interrupt from the second hardware resource occurs during the initialization process of the second OS And registering in the interrupt prohibition table managed by the first OS so as not to prohibit the interrupt of the second hardware resource by the interrupt control of the first OS
  A multi-OS control method characterized by that.

Images