JPS63298447A - Multi-operating system console control system - Google Patents

Abstract

PURPOSE:To control the input/output requests of plural operating systems OS via a nucleus OS and also to enable plural OSs to share a single console, by using a 1st OS serving as a nucleus to control all processes in a multi-operating system. CONSTITUTION:A 2nd operating system OS4 or a user task gives an input/output request to a 1st OS1 before the OS4 or the user task controlled by the OS4 gives an input/output request to an input/output control task (I/O handler) 2 which is controlled by the OS1. Thus the OS1 decides whether the OS1 itself has a privileged input/output request or not to its own received request or whether an input/output request is received or not from another task controlled by the OS1. Then the OS1 gives permission to the requester OS4 or the user task based on the result of said decision. Thus all input/output processes are carried out under the control of the OS1.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention runs different operating systems (hereinafter referred to as O8) on one computer, and operates one console terminal device (hereinafter referred to as console). (omitted) relates to a console control method for collectively managing these O8s.

[Conventional technology]

The conventional console control method is disclosed in Japanese Patent Application Laid-Open No. 61-54.
As described in Publication No. 538, this is a method in which a second operating system or a user task controlled by the second operating system makes a direct input/output request to an input/output control task controlled by the first operating system. However, in this method, the core operating system does not manage input/output requests, so if multiple input/output requests occur at the same time, or whether the input/output requests are privileged or not, control is performed by the input/output control task. Therefore, there was a problem in that the control of the first operating system, which is the core, was not intervened.

[Problem that the invention seeks to solve]

The above-mentioned conventional technology lacks the fundamental consideration that all processing in a multi-operating system is controlled by the core first operating system, which causes the above-mentioned problem.

An object of the present invention is to perform all input/output processing via a first core operating system.

Note that the method of controlling the screen by dividing it into a plurality of parts using the input/output control task may be the method according to the above-mentioned known example or another method.

[Means for solving problems]

The above purpose is to implement a second operating system (hereinafter referred to as
208) or a user task (hereinafter referred to as user task) controlled by the 208th handler (hereinafter referred to as the 10th handler) controlled by the first operating system (hereinafter referred to as TOS). Before making an input/output request to the 108th node, the 208th or user task requests input/output permission to the 108th node.
In response to this request, determines whether the 108th itself is making a privileged I/O request, or whether it is an I/O request from another task (which may be an operating system or a user task) controlled by the 108th. Decide whether or not
By granting permission to the requesting 208th or user task, it is possible to satisfy the basic operation of the operating system that all input/output processing is performed under the control of the 10th S.

[Effect]

When the I10 handler accepts an input/output request, it performs input/output processing to the console, and upon completion, sends a termination message to the iOS. Therefore, from the perspective of the 108th, the 2nd
08 or when an input/output permission request is received from a user task, the operating state of the I10 handler is determined, i.e., whether it is requesting its own input/output, requesting input/output from another task, or waiting. Since this can be easily determined, the 108th node can decide whether to grant permission to the request source or wait to grant permission until the completion message is received from the 10th handler.

When the 208th or user task receives input/output permission from the 10th S, it drives the I10 handler and performs input/output to the console.

〔Example〕

An embodiment of the present invention will be described below with reference to FIGS. 1, 2, and 3.

Figure 1 is a configuration diagram of the entire system, where 1 is the core of the system, 108, and 2 is the I that controls input/output to the console.
10 handlers have the function of splitting the screen of one console to display multiple O8s, 3 is the console, 4 is the 208th handler controlled by the 1081st handler, and 5 is the 2nd handler.
This is a user task controlled by 082. The flow when the 2084 or user task 5 issues an input/output request to the console 3 will be explained with reference to FIG. No. 2084
Alternatively, when user task 5 (hereinafter the two parties are collectively referred to as request sources) requires input/output processing, it requests input/output permission from the 1081st task as shown in block 10. In block 11, if there is no permission from 1g1O81, the requestor waits until permission is obtained as shown in block 12, or waits until permission is obtained while performing other processing. If permission is granted in block 11, the request source requests input/output from the I10 handler 2 as shown in block 13. I10
Handler 2 performs input/output processing to the console according to the input/output request, and upon completion, sends a termination message to the 1081st
Send to.

Next, the flow of the 1081st process for managing input/output will be explained with reference to FIG. When an input/output permission request is received from the request source in block 20, it is determined whether the 1081st itself is requesting input/output or an input/output request is being received from another task, as shown in block 21 and block 4. , if an input/output request is in progress, wait for the currently executing input/output request to be completed as shown in block 22 or block 24 (as described above, wait for ■10 handler 2 to send a completion message) As shown in block 25, input/output permission, that is, the right to use I10 handler 2, is granted to the requester.

〔Effect of the invention〕

As explained above, according to the present invention, the core O8 manages the input/output requests of multiple O8s (including user tasks), and multiple O8s can jointly use one console. There are advantages.

[Brief explanation of drawings]

FIG. 1 is a configuration diagram of a multi-operating system to which the present invention is applied, and FIG. 2 is a flowchart showing the flow when a second operating system or a user task makes an input/output permission request to the first operating system. FIG. 3 is a flowchart showing the flow when the first operating system processes an input/output permission request. 1...First operating system 2...I10
Handler 3...Console 4...Second operating system 5...User task representative Patent attorney Masao Ogawa

Claims (1)

[Claims] 1. In a multi-operating system that runs multiple operating systems in parallel,
The input/output processing of each operating system is performed by dividing the screen on the console into multiple parts and displaying them using one input/output control task, and the first operating system (the core operating system) controls the input/output processing of each operating system. The input/output requests from user tasks controlled by the second operating system or the second operating system are managed by the first operating system, and the actual input/output is handled by the first operating system, the second operating system, or the user. A multi-operating system console control method characterized in that a task performs this by making an input/output request to the input/output control task.