JP2007328782A - Method, device and computer program for sharing kernel service among kernels - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method, device and computer program for sharing kernel services among kernels. <P>SOLUTION: A partition manager receives from an application in a logical partition, a first system call for a kernel service from a first kernel. The first system call has form and content compatible with the first kernel. In dependence upon the first system call, a second system call for the kernel service from a second kernel is generated. The second system call has form and content compatible with the second kernel. The second system call is sent through the partition manager to the second kernel for execution. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to the field of data processing, and more particularly to a method, apparatus, and computer program for sharing kernel services between kernels.

  A thread is a unit of software execution in a multi-thread computer. That is, a thread is an executable component of work in a computer system. A thread can be represented as a separate stream of executable computer program instructions. In such a computer, the software program is a software program such as a code segment and offset register, a data segment and offset register, a stack segment and offset register, a flag register, an instruction pointer register, etc. It is executed in a unit of execution called a “process” that contains all the processor registers necessary for execution. For efficiency, “processes” are further organized as threads. Each thread of the process individually owns all the attributes necessary for execution, except sharing memory with all other threads of the process, thereby allowing operating system thread switching (context・ The overhead related to the switch is reduced.

  In this specification, two modes of multithreading are considered: simultaneous multithreading (SMT) and single thread (ST) multithreading. ST multithreading is time-multiplexed multithreading, that is, multithreading through the use of time slices. In ST mode, both individual threads and virtual processors are assigned to a portion of the processor's computing capacity allocated as a segment of time. Each segment of time is called a “time slice”.

  Some processors have a feature called “simultaneous multithreading” or “SMT” that accepts computer instructions from multiple threads simultaneously. The idea behind SMT is to share the processor hardware on a single chip among multiple threads in a multithreaded workload. SMT is a technique in which instructions for a single physical processor are generated by a plurality of independent threads in a single processing cycle. In conventional processor architectures, only one thread issues instructions to one processor at a time. An example of a processor that implements the SMT disclosed herein is the IBM Power5 processor.

  The SMT is implemented on a physical processor, each capable of accepting instructions from multiple execution threads simultaneously. Further, in SMT mode, both virtual processors and threads executing on virtual processors can be allocated through time slices. A thread that runs on a virtual processor in SMT mode can also be considered to run on a logical processor. Thus, a virtual processor running on a physical processor in SMT mode can also be viewed as supporting multiple logical processors. Whether a thread is executed in ST mode or SMT mode, a thread executing in a logical processor does not know the logical or virtual nature of the processor and regards it as a conventional processor.

  Multiple processing is implemented in a computer that supports a plurality of logical partitions for each partition in ST mode or SMT mode. Each partition implements an individual operating system as a whole, including an individual kernel. The kernel supports applications running in logical partitions by providing kernel services. The types of services provided by the kernel are generally the same, but different kernels can implement services in different ways. For this reason, some kernels are superior to other kernels in providing kernel services. However, in the prior art, a kernel that performs good services cannot share such services with other kernels, and cannot even share with other kernels of the same type. For example, in the case of a UNIX® kernel with a good disk I / O driver, it was of the exact same type and version as other UNIX® kernels Even so, the disk I / O driver may not be made available to execution threads that run against such other UNIX® kernels.

  It is an object of the present invention to provide a method, apparatus, and computer program for sharing kernel services between kernels.

  The method of the present invention allows a partition manager to receive a first system call from an application in a logical partition that has a format and content compatible with a first kernel and that seeks kernel services from the first kernel. Generating a second system call having a format and content compatible with a second kernel and seeking a kernel service from the second kernel according to the first system call; Sending two system calls to the second kernel for execution via the partition manager.

  The above and other objects, features and advantages of the present invention will be apparent from the following more detailed description of the embodiments of the present invention illustrated in the accompanying drawings. In the drawings, like reference numerals generally refer to the same elements of the embodiments of the present invention.

  Exemplary methods, apparatus, and computer programs for sharing kernel services between kernels according to embodiments of the present invention will be described with reference to the accompanying drawings. Sharing kernel services between kernels according to the present invention is implemented on an automated computing machine, ie, one or more computers. FIG. 1 shows a block diagram of an automated computing machine including an exemplary computer 152 useful for sharing kernel services between kernels, according to an embodiment of the present invention. The computer 152 of FIG. 1 includes a number of physical processors 156 and random access memory (RAM) 168. RAM 168 is connected to physical processor 156 and other components of the computer via system bus 160.

  RAM 168 includes a logical partition 114 that includes application program 108, operating system 110, and logical processor 106, as well as a partition partition that includes two or more kernels 102, 104, virtual processor 122, and kernel shared interface 124. Manager 112 is stored. A logical partition (LPAR) 114 is a data structure and distribution that allows computer resource distribution in a single computer to organize computer functions as if the computer were two or more independent computers. A set of services. Each logical partition is assigned all the resources necessary to operate as if it were an independent computer including processor time, memory, operating system, etc. Resources that are made available to applications through logical partitions and logical partitions are sometimes collectively referred to as “virtual machines”. For convenience of explanation, the system of FIG. 1 includes only one logical partition, but a system sharing kernel services between kernels according to embodiments of the present invention can support any number of logical partitions. .

  The application program 108 is a module of user level computer program code. Application programs are non-privileged code that must gain access to computer resources by calls through the operating system kernel.

The operating system 110 is a system software layer that schedules threads and provides functions for making system resources available to threads, including memory access, access to I / O resources, and the like. The operating system also controls allocation and authorization for accessing computer resources. The operating system recognizes input from the keyboard, sends output to the display screen, tracks files and directories on the disk drive, and controls peripheral devices such as disk drives and printers Perform basic low-level tasks like The operating system is also responsible for security and ensures that unauthorized users do not access the system and that threads only access resources that they are authorized to access. Many operating system functions are implemented by the kernel, in this example by the primary kernel 102 or the shared kernel 104. A useful operating system for sharing kernel services between kernels according to embodiments of the present invention is a multi-threading operating system, examples of which are UNIX, Linux, Windows (registered). (Trademark) XP, AIX (TM), IBM's i5 / OS (TM), and others as would occur to those skilled in the art.

  Logical processor 106 is an operating system structure for scheduling threads for execution in a logical partition. That is, operating system 110 schedules threads for execution on logical processor 106 rather than scheduling threads for execution on physical or virtual processors. Scheduling threads in a logical processor provides an easy-to-use structure and processing, in which case the thread appears to have all the resources of the entire logical partition freely from the thread perspective. A virtual processor is allocated a portion of a physical processor. However, a logical processor is logically one complete processor, despite the fact that it, like all other executions in the machine, is physically running in a fine time slice. Thus, a thread running on a logical processor in LPAR appears to have all the resources of one completely independent computer when viewed from that thread. That is, a logical processor is a target for dispatching threads by a dispatcher in an operating system operating in one partition, and a virtual processor is dispatched by a partition manager. In the LPAR operating in the ST mode, the correspondence between the logical processor and the virtual processor is one-to-one, and one logical processor corresponds to each virtual processor. In LPAR operating in SMT mode, the correspondence between logical processors and virtual processors is N-to-1 where N is the number of logical processors supported in one virtual processor. That is, N logical processors correspond to each virtual processor.

  The virtual processor 122 is a subsystem consisting of data structures and computer program instructions, and implements the allocation of processor time to logical partitions. A shared pool of physical processors supports the allocation (in time slices) of partial physical processors to logical partitions. Such partial physical processors that are shared in a time slice are called “virtual processors”. Physical processors held in the shared processing pool are shared among logical partitions. In the example in this specification, physical processors are shared according to a processing unit in which 1.0 represents the processing capability of one physical processor. The assignment of threads to be executed in the virtual processor is generally performed by the assignment of threads to be executed in the logical processor of the virtual processor. In the ST mode, each virtual processor has one logical processor. However, in the case of SMT mode, in these examples, each virtual processor has two logical processors.

  The partition manager 112 of FIG. 1 is a system software layer that runs under a logical partition. That is, the partition manager 112 operates between the logical partitions and the basic computer hardware, ie, the physical computer components including the physical processor 156. The partition manager assists in setting up and executing multiple operating systems and applications in multiple logical partitions. Among other things, the partition manager assists users or system administrators to set up partitions, virtual processors, and logical processors. The partition manager schedules and dispatches virtual processors on physical processors just as the operating system kernel on computers that support multiple logical partitions schedules and dispatches threads on logical processors.

  Because the operating system in a logical partition is often used to run a specific application or set of applications, a partition manager can run multiple operating systems on a single computer to reduce overall hardware costs. -Allows the system and their applications to run. Manufacturing and test systems can run simultaneously on the same hardware. In addition, the partition manager supports multiple logical partitions, allowing various operating systems such as Windows and Linux to share the same basic computer hardware. A partition manager is a type of software that may also be referred to as a “hypervisor”, “virtualization manager”, or “virtual machine monitor”.

In the example of FIG. 1, the partition manager 112 includes kernels 102 and 104. The kernel is the core of the operating system. The kernel is a privileged module, also called “system executive” or “system monitor”. The kernel is the software responsible for making secure access to computer system hardware (including access to memory, I / O resources, etc.) for execution threads in applications and other operating system components. is there. The kernel also schedules execution threads that form application programs and operating system processes. The kernel generally also provides services for interprocess communication and synchronization, such as memory locks, signals, and semaphores. The kernel also generally provides a hardware abstraction (a set of instructions that is universal for all devices of a certain type) to hide potential complexity from applications and from other components of the operating system. . The hardware abstraction component relies on software drivers to provide functionality specific to the hardware device's manufacturing specifications. In short, the kernel provides the following kernel services.
• Control and arbitration of access to system hardware.
Implement and support basic abstractions such as processes, threads, files, devices, etc.
Allocation and scheduling of system resources such as memory, processor, disk, file description, process description, thread description, etc.
• Enhanced security and protection of system resources.
Respond to user and application requests for service via system calls.

  The operating system kernels 102, 104 that were previously installed in the operating system are installed in this example in the partition manager 112, so that system calls from application programs seeking kernel services are partitioned.・ Directed through the manager. Installing the kernel on the partition manager saves system resources by allowing multiple logical partitions to use the same instance of the kernel. The installation of the kernel in the partition manager is described in detail in US patent application Ser. No. 11/301113 entitled “Sharing A Kernel Of An Operating System Among Logical Partitions”.

  In the computer illustrated in FIG. 1, the partition manager 112 shows the kernel sharing interface 124. The kernel sharing interface 124 is an application programming interface (API) and, for example, computer program instructions configured to facilitate sharing of kernel services between kernels according to embodiments of the invention. It is a computer software module implemented as a library. The kernel sharing interface 124 receives a first system call for kernel service from the first kernel 102 from the application 108 in the logical partition 114, and receives a second system call for kernel service from the second kernel 104. It includes computer program instructions that occur in response to the first system call and that can send the second system call for execution to the second kernel 104 via the partition manager 112. The kernel sharing interface 124 in this example also includes computer program instructions that can receive responses from the kernel 104 that provides kernel services and send responses to the application 108 in the logical partition 114. The kernel sharing interface 124 may also include computer program instructions that can ensure that the response has a format and content compatible with the first kernel 102.

  In the example of FIG. 1, computer software components such as application 108, logical partition 114, logical processor 106, operating system 110, partition manager 112, virtual processor 122, kernel 102, 104, etc. are located in RAM 168. It is shown. However, it will be apparent that many components of such software may be stored in non-volatile memory 166. The computer 152 of FIG. 1 includes non-volatile computer memory 166 connected to the physical processor 156 and other components of the computer 152 via a system bus 160. Non-volatile computer memory 166 includes hard disk drive 170, optical disk drive 172, electrically erasable read-only memory space (so-called “EEPROM” or “flash” memory) 174, RAM drive (not shown). Or other types of non-volatile memory that would occur to those skilled in the art.

  The example computer 152 in FIG. 1 includes one or more input / output interface adapters 178. The input / output interface adapter in the computer is software software for controlling output to a display device 180 such as a computer display screen and user input from a user input device 181 such as a keyboard and mouse. It implements user-oriented input / output via drivers and computer hardware.

  The example computer 152 in FIG. 1 includes a communication adapter 167 for performing data communication with other computers 182. Such data communication can also be performed via a data communication network, such as, for example, an IP network and in other ways that can occur to those skilled in the art. The communication adapter implements hardware level data communication in which one computer sends data communication to another computer directly or over a network. Examples of communication adapters useful for sharing kernel services between kernels in accordance with embodiments of the present invention include wired dial-up communications, Ethernet (IEEE 802.3) adapters for wired network communications, and wireless Includes IEEE 802.11b adapter for network communication.

For further explanation, FIG. 2 shows a functional block diagram illustrating an exemplary system for sharing kernel services between kernels in accordance with an embodiment of the present invention. The system of FIG. 2 includes two logical partitions: an ST mode logical partition 202 and an SMT mode logical partition 204. The system of FIG. 2 includes six logical processors: two logical processors 230, 232 for logical partition 202 and four logical processors 234, 236, 238, 240 for logical partition 204. The system of FIG. 2 further includes four virtual processors: two virtual processors 242, 244 assigned to logical partition 202 and two virtual processors 246, 248 assigned to logical partition 204. The system of FIG. 2 further includes three physical processors 250, 252 and 254. In this example, the processing capacities of the three physical processors 250, 252 and 254 are allocated to the logical partitions as follows.
• All processing capacity of the physical processor 250 is fully allocated to the virtual processor 242, and thus the logical processor 230 may use the entire physical processor 250.
-Half of the processing capacity of the physical processor 252 is allocated to the virtual processor 244, so the logical processor 232 may use half of the physical processor 252 in the time slice.
-Half of the processing capacity of the physical processor 252 is allocated to the virtual processor 246. Virtual processor 246 is assigned to logical partition 204 operating in SMT mode, including two logical processors 234, 236 for virtual processor 246. Logical processors 234 and 236 may each use 1/4 of the processing capacity of physical processor 252 in the time slice.
All processing capacity of the physical processor 254 is allocated to the virtual processor 248 Virtual processor 248 is assigned to logical partition 204 operating in SMT mode, including two logical processors 238, 240 for virtual processor 248. Logical processors 238 and 240 may each use half of the processing capacity of physical processor 254 in a time slice.

  The system of FIG. 2 includes a partition manager 112. The partition manager is a system software layer that runs under a logical partition. That is, the partition manager 112 operates between logical partitions and physical computer components that are basic computer hardware including physical processors 250, 252 and 254. The partition manager assists in setting up and executing multiple operating systems and applications in multiple logical partitions. Among other things, the partition manager assists users or system administrators to set up partitions, virtual processors, and logical processors. The partition manager schedules and dispatches virtual processors on physical processors just as the operating system kernel on computers that support multiple logical partitions schedules and dispatches threads on logical processors. Because the operating system in a logical partition is often used to run a specific application or set of applications, the partition manager runs multiple operating systems and their applications on a single computer And reduce the overall hardware cost. Manufacturing and test systems can run simultaneously on the same hardware. In addition, the partition manager supports multiple logical partitions, allowing different operating systems such as Windows and Linux to share the same basic computer hardware.

  In the example of FIG. 2, the partition manager 112 includes a kernel shared interface 124. The kernel sharing interface 124 is an application programming interface, or “API”, and a library of computer program instructions configured to facilitate sharing of kernel services between kernels in accordance with embodiments of the present invention. As a computer software module. The kernel sharing interface 124 receives a first system call for a kernel service from the first kernel 102 from the applications 206 and 208 in the logical partitions 202 and 204, and the kernel from the second kernel in response to the first system call. Includes computer program instructions that can generate a second system call for service and send a second system call to the second kernel 104 via the partition manager 112 for execution. The kernel sharing interface 124 further receives a response from the kernel 104 that provides kernel services and can send a response to the application 206, 208 in the logical partition 202, 204 that sent the first system call. Contains program instructions. The kernel sharing interface 124 may also include computer program instructions that can ensure that the response has a format and content compatible with the first kernel 102.

  The system of FIG. 2 includes operating systems 210 and 220 in logical partitions 202 and 204, respectively. In this example, operating system functions that can be accessed directly by the application or user remain in the logical partition, while operating system kernels 102, 104 are installed in the partition manager 112. Such functions include support for graphical user interface (GUI) 212,222. Such functionality also includes support for shells 214, 224 that provide a command line interface to operating system utilities and library functions, for example. Operating system functions that can be accessed directly by the application or user also include system utilities 216, 226. System utilities generally read, set, and search text in a file, for example, a program for creating, opening, or deleting a file, a program for creating and navigating a directory of files, and so on. Including a program for system management that can be accessed through a GUI or shell, such as

  Operating system functions that can be directly accessed by an application or user may include a system call library (218, 228) or may be implemented as a system call library (218, 228). The system call library is an application program interface (API) that allows access to hardware-dependent services and other protected systems by calls to privileged software routines in the kernels 102, 104. ). Such calls to privileged code in kernel space are caused by interrupts or software traps that are called from within a function of the system call library. Access to function calls in a system call access library is generally based on one or more system call libraries being loaded into an application or utility, or other libraries that can be dynamically loaded at runtime (dynamically linked Resulting in a compiled library, or “DLL”).

  For further explanation, FIG. 3 shows a state diagram illustrating an exemplary thread state for sharing kernel services between kernels in accordance with an embodiment of the present invention. A circle in FIG. 3 represents a thread state. The arrows between the circles represent the state transitions brought about by the kernel function. The thread states represented in FIG. 3 include a create state 302, an ready state 304, an execute state 306, a wait state 308, and a stop state 310. When a thread is first created at the request of another thread, it is temporarily in the created state 302, giving kernel time to collect information and resources for that thread. As soon as the kernel prepares the thread for execution, the thread is “started (303)”, ie moved to the ready state 304.

  A thread in ready state 304 is placed in a ready queue (not shown) and waits for an opportunity to execute. The process for determining which ready thread is executed next is called “scheduling”. There are many scheduling algorithms such as FIFO, round robin, priority etc. The kernel function for moving a thread from the ready state to the running state is called "dispatch (312)". Since a thread is in an execution state when dispatched, “dispatch”, “running” and “execution state” are generally synonymous.

  A thread is currently assigned to execute in a logical processor when it is dispatched, ie, in the execution state 306. Whether a thread is physically executing depends on whether the virtual processor of the logical processor is currently dispatched through its partition manager, i.e. whether it is executing in a time slice on the physical processor . An ready queue for a logical processor may include one, two, or more threads in an ready state waiting to be executed on the logical processor. Usually, only one thread at a time is placed in the running state in the logical processor.

  A thread may lose ownership of the logical processor and be moved from the running state to the ready state due to preemption or time out 314. When a thread with a higher priority enters the ready queue for that logical processor, that thread is preferentially used. A thread times out if it retains ownership of the logical processor, i.e. remains running throughout its time slice.

  A thread can also exit the execution state 306 by issuing a system call 316 and entering a wait state 308 to wait for the completion of the system call. Such a system call may be, for example, an intentional request to sleep or wait for a period of time, a request for data to be read from or written to disk, or data to be input / output It may be a request for some service provided by the kernel, including a request to read from a resource or to be written to an I / O resource.

  For further explanation, FIG. 4 shows a state diagram illustrating exemplary virtual processor states for scheduling virtual processors in a computer system sharing a kernel in accordance with an embodiment of the present invention. The circle in FIG. 4 represents the state of the virtual processor. The arrows between the circles represent the state transitions brought about by the partition manager function. The virtual processor states shown in FIG. 4 include a create state 322, an ready state 324, an execute state 326, a wait state 328, and a stop state 330. A virtual processor is typically temporarily in a created state 322 when first created at boot time, giving the partition manager time to gather information and resources for that virtual processor. When the partition manager prepares the virtual processor for execution, the virtual processor is “started” (323), ie, moved to the ready state 324.

  A virtual processor in ready state 324 is placed in a ready queue (not shown) and waits for an opportunity to execute. The partition manager schedules virtual processors for operation according to one or more scheduling algorithms such as round robin, priority, and the like. The partition manager dispatches the single virtual processor from the ready queue that is currently most suitable for the actual ownership of the physical processor to which the virtual processor is assigned from the ready state to the running state. Usually, only one virtual processor is placed in the running state in the physical processor at a time.

  The virtual processor may lose ownership of the physical processor due to preemption or time out 334 and may be moved from the running state to the ready state. A virtual processor is preferentially used when a virtual processor with a higher priority enters the ready queue for the physical processor. A virtual processor times out if it retains ownership of the physical processor throughout its time slice, i.e., remains running.

  The virtual processor can also exit the execution state 326 by issuing a system call 336 and entering a wait state 328 to wait for the completion of the system call. Such system calls are intentional requests to sleep or wait for a period of time, requests that data be read from or written to disk, and data is from an I / O resource. This includes requests that are read or written to I / O resources. Keystrokes occur when a thread running in a virtual processor, i.e., a thread running in a logical processor of a logical partition, generates a system call, e.g., waiting for keyboard input or reading a file from disk It is also possible for the virtual processor to determine that the virtual processor does not need to occupy the physical processor just because it does nothing until the disk read is completed. In this situation, the virtual processor may sleep for a period of time, eg, 1/10 second. Returning the virtual processor from the wait state to the ready state is referred to as a “wake-up” 338 of the virtual processor.

  For further explanation, FIG. 5 shows a functional block diagram illustrating a further exemplary system for sharing kernel services between kernels in accordance with an embodiment of the present invention. The system of FIG. 5 includes a logical partition 114 executing an application 108, kernels 102, 104 sharing kernel services 404, 406, and a kernel sharing interface 402, all of which run on a computer 152.

  In the system of FIG. 5, the application 108 sends a system call to the kernel 102 in the partition manager 112 via the kernel sharing interface 402. The kernel sharing interface 402 performs two-way communication with the kernels 102, 104 in the partition manager 112 and converts the format and content of the communication into the appropriate one for the receiver, It is a module. In this example, application program 108 issues a system call 434 to kernel 102 for a kernel service 404 that is configured for kernel 102 to obtain from kernel 104. The system call 434 is sent to the kernel 102 via the partition manager 112 in the form of an interrupt vector. The kernel 102 receives a system call having a format and content (parameter values and parameter sequence) compatible with the kernel 102, and the kernel service required by the system call is provided by the second kernel 104. Decide that it should be. The kernel 102 sends a system call for kernel services to be provided by the kernel 104 to the kernel shared interface 402 with instructions for sending the system call to the kernel 104 (410).

  In response to an instruction to send a system call to the kernel 104, the kernel shared interface 402 generates a second system call for kernel services from the kernel 104. The kernel shared interface 402 generates system calls to the kernel 104 that have a format and content (parameter values and parameter sequences) that are compatible with the kernel 104. The kernel sharing interface 402 sends a second system call to the kernel 104 for execution (416).

  The kernel 104 provides a kernel service 406 in response to receiving the second system call. If the cursor service 406 generates a response, the kernel 104 sends the response to the kernel shared interface 402 (418). The response generated by the kernel 104 has a format and content that is compatible with the kernel 104.

  When the kernel shared interface 402 receives a response from the kernel 104, the kernel shared interface 402 generates a second response. The second response generated by the kernel shared interface 402 has a format and content that is compatible with the kernel 102. The kernel shared interface 402 sends a second response to the kernel 102 (412). The kernel 102 sends the second response to the requesting application 108 (436).

  For further explanation, FIG. 6 shows a functional block diagram illustrating a further exemplary system for sharing kernel services between kernels according to an embodiment of the present invention. The system of FIG. 6 includes a logical partition 114 executing an application 108, a partition manager 112, and kernels 102, 104 sharing a kernel service 406. These all run on the computer 152.

  In the system of FIG. 6, the application 108 sends a system call to the kernel 102 in the partition manager 112 (438). The kernel 102 includes a shared module 420 and a kernel shared interface 422. Shared module 420 is a software module of kernel 102 that determines whether the kernel service called in a system call is to be provided by another kernel. The kernel sharing interface 422 is a software module of the kernel 102 that directs communication with the kernel 104 and converts the communication into a form and content appropriate for the recipient of the communication. Shared module 420 determines whether a system call received from application 108 is requesting a kernel service to be provided by second kernel 104. If the system call received from the application 108 includes a call for a kernel service to be provided by the second kernel 104, the kernel shared interface 422 has a format and content compatible with the second kernel 104. 2 Generate a system call. The kernel sharing interface 422 sends the second system call to the second kernel 104 (426).

  In the example of FIG. 6, the kernel 104 includes a kernel shared interface 424. The kernel shared interface 424 calls the kernel service 406 (428) and receives a response from the kernel service 406 if the kernel service 406 generates a response. The response generated by the kernel service 406 has a format and content that is compatible with the kernel 104. The kernel sharing interface 424 generates a second response having a format and content that is compatible with the kernel 102. The kernel sharing interface 424 sends a second response to the kernel 102 (432). The kernel 102 receives the second response and returns it to the requesting application 108 (440).

  For further explanation, FIG. 7 shows a flowchart illustrating an exemplary method for sharing kernel services between kernels in accordance with an embodiment of the present invention. The method of FIG. 7 includes two or more applications in one or more logical partitions 114, one or more applications 108 running in one or more logical partitions 114, a partition manager 112, and a partition manager 112. It can be executed by the computer 152 having the kernels 102 and 104 described above. In the example of FIG. 7, the partition manager 112 allocates resources to a logical partition when the logical partition is booted. Upon booting the logical partition 114, the partition manager 112 allocates the first kernel 102 as a resource for the logical partition 114 in order to provide kernel services to the application 108 running on the logical partition 114.

  The method of FIG. 7 includes a step 508 in which the partition manager 112 receives a first system call 502 from the application 108 in the logical partition 114 for kernel service 522 from the first kernel 102. In the example of FIG. 7, a system call is an instruction generated in the kernel for execution of a kernel service by an application via a function of the system call library.

  The first system call 502 has a format 504 and content 506 that are compatible with the first kernel 102. In the example of FIG. 7, the format 504 of the system call 502 is a sequence of call parameters, and the contents 506 of the system call 502 are system call identification information and call parameter values. The identification information of the system call can be represented by the name of the system call or the value of the interrupt vector. Since the logical partition 114 appears to the application 108 to be a complete computer with only the kernel 102 to provide kernel services, the format and content of the system call 502 is compatible with the first kernel 102. Have Application 108 and logical partition 114 do not know any kernel other than kernel 102. Thus, application 108 and logical partition 114 provide kernel 102 with system calls that have a format and content compatible with kernel 102.

The method of FIG. 7 generates a second system call 512 that seeks a kernel service 522 from the second kernel 104 based on the first system call 502 (step 510). Second system call 512 has a format 514 and content 516 that are compatible with second kernel 104. In the example of FIG. 7, the step 510 of generating a second system call 512 for kernel service 522 from the second kernel 104 is performed by the partition manager 112. The partition manager 112 can generate the second system call by using a data structure as shown in Table 1 below, for example.

  Each record in Table 1 includes a logical partition identifier, a primary kernel identifier, a shared kernel identifier, and a received system call and a generated system call that specifies the type and content of the system call to be sent to the shared kernel. Associate with. In Table 1, the received call has both the format, eg, the parameters specified in the call and their colors, and the content, eg, the keyword and parameter values used to invoke the function. In the first record of Table 1, for example, the format of the received call includes the parameters “x, y, z” in that order, and the content includes the command keyword “F” and the values of x, y, z. In the example of FIG. 7, kernel 102 is the primary kernel because it is a kernel assigned to provide kernel services to logical partition 114. Since the kernel 104 is a kernel that shares one of its services, it is a shared kernel in the example of FIG. System call 502 is a received call in the example of FIG. 7, and second system call 512 is a generated call. When the partition manager receives a system call from an application in a logical partition, it searches for the received system call in a data structure such as Table 1 by using the primary kernel identifier associated with the logical partition; Identify the format and content required for the system call that was issued. Thus, the partition manager generates the second system call by forming an instruction with appropriate keywords, parameters, etc. to provide the second system call with a format and content compatible with the shared kernel.

  The method of FIG. 7 includes a step 518 of sending a second system call 512 to the second kernel 104 for execution. In the example of FIG. 7, the partition manager 112 that has generated the second system call 512 sends the second system call to the second kernel 104. The partition manager can identify the second kernel 104 with reference to the data structure as shown in Table 1. For example, in the first record of Table 1, the primary kernel identifier “102” with format and content “F (x, y, z)” received from the logical partition for the primary kernel with logical partition identifier “114”. The shared kernel for the system call to the primary kernel with 対 応 corresponds to the shared kernel having a shared kernel identifier of “104”. Thus, the partition manager in this example generates a call with the form and content “F (x, y, z)” and sends the generated call to the second kernel 104 for execution. The step 518 of sending the second system call 512 to the second kernel 104 for execution is as described above in connection with reference numbers 124, 402, 422, 424 in FIGS. It may be performed by use of a shared interface.

  The method of FIG. 7 further includes a step 520 in which the second kernel 104 provides a kernel service 522. The second kernel 104 in the example of FIG. 7 provides kernel services by executing the second system call 512 using the parameters specified by the contents 516 of the second system call 512.

  The method of FIG. 7 further includes a step 550 of providing a response to the second system call 512 as part of the step 520 of providing the kernel service 522. The kernel 104 can also provide a response as part of providing the kernel service, for example, when the kernel service 522 generates a response. Those of ordinary skill in the art having the benefit of this specification will recognize that not all kernel services will generate responses to system calls. Nonetheless, kernel services that do not respond are also within the scope of the present invention.

  In the method of FIG. 7, the response 552 provided by the kernel 104 has a format 554 and content 556 compatible with the kernel 104. In the method of FIG. 7, the kernel 104 provides a response 552 as if the second system call 512 was a system call from an application that uses the kernel 104 to provide kernel services. Accordingly, the kernel 104 provides the format 554 and content 556 that an application using the kernel 104 for kernel services expects in a response from the kernel 104, ie, a response having a format and content compatible with the kernel 104. A response 552 is provided.

  The method of FIG. 7 further includes a step 558 of receiving a first response 552 from the kernel 104 and a step 560 of generating a second response 526. In the example of FIG. 7, the partition manager 112 receives a response from the kernel 104 (step 558) and generates a second response 526 (step 560). The second response 526 generated by the partition manager 112 has a format 528 and content 530 that are compatible with the kernel 102. Since the application 108 expects the response to the system call 502 to come from the kernel 102, and thus the response has a format and content compatible with the kernel 102, the second response 526 is It has a compatible format 528 and content 530.

  The method of FIG. 7 further includes a step 524 of sending a response to the application 108 in the logical partition 114. In the example of FIG. 7, the step 524 of sending a response to the application 108 in the logical partition 114 is performed by the partition manager 112. From the perspective of the application 108, it appears that the kernel 102 provided the kernel service 522.

  For further explanation, FIG. 8 shows a flowchart illustrating a further exemplary method for sharing kernel services between kernels in accordance with an embodiment of the present invention. The method of FIG. 8 is similar to the method of FIG. That is, the method of FIG. 8 includes a step 508 in which the partition manager 112 receives a first system call 502 from the application 108 in the logical partition 114 for a kernel service 522 from the first kernel 102. In this case, the first system call 502 has a format 504 and content 506 that are compatible with the first kernel 102. Similar to the method of FIG. 7, the method of FIG. 8 includes a step 510 of generating a second system call 512 that seeks a kernel service 522 from the second kernel 104 according to the first system call 502. This second system call 512 has a format 514 and content 516 that are compatible with the second kernel 104. Similar to the method of FIG. 7, the method of FIG. 8 includes a kernel service 522 that includes a step 518 of sending a second system call 512 to the second kernel 104 for execution and a step 550 of providing a response 808. Providing step 520. All of these steps generally operate as described in connection with the method of FIG. However, unlike the method of FIG. 7, the first kernel 102 generates a second system call 512 in the method of FIG.

  The method of FIG. 8 further includes a step 602 in which the first kernel 102 receives the first system call 502. In the example of FIG. 8, the partition manager 112 receives the first system call 502 (step 508), determines that the kernel 102 will provide kernel services to the application that issued the system call, and Send the call to the kernel 102.

The method of FIG. 8 further includes a step 604 where the first kernel 102 determines that the kernel service 522 is to be provided by the second kernel 104. The kernel 102 may determine that the kernel service 522 should be provided by the kernel 104, for example, by using a data structure as shown in Table 2 below.

  Each record in Table 2 associates the received system call with the shared kernel that is to provide the kernel service identified in the system call, and the format of the system call for kernel service to the shared kernel And specify the contents. If the received system call is associated with a shared kernel in such a data structure, the kernel 102 should have the kernel service called by the system call provided by the second kernel, ie the shared kernel Can be determined.

  The method of FIG. 8 further includes a step 510 in which the first kernel 102 generates a second system call 512 for kernel service 522 in accordance with the first system call 502. The kernel 102 can generate the second system call 512 based on the data structure as shown in Table 2. In Table 2, the received system call is both in the form (eg, parameters specified in the call and their order) and content (eg, command keywords and parameter values used to invoke the function) Have For example, in the first record of Table 2, the format of the received system call includes the parameters “x, y, z” in that order, the content is the command keyword “F” and the values of x, y, and z including. In the example of FIG. 8, kernel 102 is the primary kernel because it is assigned to provide logical services to logical partition 114. In the example of FIG. 8, the kernel 104 is a shared kernel because it is a kernel that shares one of its services. System call 502 is the received system call in the example of FIG. 8, and second system call 512 is the generated system call. When the kernel 102 receives a system call from the partition manager 112, it uses the identifier of the received system call to identify the identity of the shared kernel that provides the kernel service and the shared kernel that seeks the kernel service. The format and content required for the system call generated can be retrieved in a data structure such as Table 2. Thus, the kernel 102 can generate the second system call 512 in the correct format to be compatible with the shared kernel by forming instructions with appropriate keywords and parameters.

  The method of FIG. 8 includes a step 520 in which the second kernel 104 provides a kernel service 522 that includes a step 550 in which a response generated by the kernel service 522 is provided. In this example, the second kernel 104 provides the first kernel 102 with a response 808 to the second system call. Note that the response 808 has a format 810 and content 812 that are compatible with the first kernel 102. Thus, the kernel 104 in this example is configured with sufficient information to allow a response compatible with the kernel 102 to be formulated. Alternatively, kernel 104 may provide a response that has a format and content that is compatible with kernel 104, and transforms the response so that kernel 102 has a format and content that is compatible with kernel 102. It may be configured to. Either way, by the time the response is returned to the requesting partition and the requesting application, the response will have a format and content that is compatible with the kernel 102. This is because return data compatible with the kernel 102 is expected by the requesting application.

  The method of FIG. 8 further includes receiving 814 a response 808 at the first kernel 102 and sending 816 a response from the first kernel 102 to the application 108. Since the response 808 in this example already has a format 810 and content 812 that are compatible with the kernel 102, sending a response 816 from the first kernel 102 to the application 108 sends an unmodified response through the kernel 102 to the application 108. May be executed.

  For further explanation, FIG. 9 shows a flowchart illustrating a further exemplary method for sharing kernel services between kernels in accordance with an embodiment of the present invention. The method of FIG. 9 is similar to the method of FIG. That is, the method of FIG. 9 includes step 508 in which the partition manager 112 receives a first system call 502 from the application 108 in the logical partition 114 for a kernel service 521 from the first kernel 102, and the first system call. Generating a second system call 704 for a kernel service 522 from the second kernel 104 according to the call 502; The first system call 502 has a format 504 and contents 506 that are compatible with the first kernel 102. In this example, kernel service 521 and kernel service 522 are equivalent kernel services, such as disk I / O requests, memory allocation requests, and the like. The kernel service 521 is in the form of a service as provided by the kernel 102, and the kernel service 522 is in the form of a service as provided by the kernel 104. The kernel 102 is configured to obtain on request the type of service represented by the service 521 from the kernel 104. The kernel 104 is configured to share a kernel service 522 in accordance with an embodiment of the present invention.

  However, unlike the method of FIG. 7, the first kernel 102 generates a second system call 704 in the method of FIG. Further, in the method of FIG. 9, step 510 of generating a second system call for kernel service 522 from second kernel 104 according to the first system call is performed by step 702 generating general system call 704. Is done. The general system call 704 in this example is a system call having a general format 706 and a general content 708. The generic format and generic content are, in this example, formats and content that are accepted as compatible by multiple kernels including the second kernel 104.

  The method of FIG. 9 further includes a step 518 of sending a second system call, a general system call 704, to the second kernel 104 for execution. In the example of FIG. 9, when the partition manager 112 generates a general-purpose system call 704, it sends it to the second kernel 104. The partition manager can identify the second kernel 104 with reference to the data structure as shown in Table 1. The step 518 of sending the generic system call 704 to the second kernel 104 for execution is the kernel sharing, as described above with reference to reference numerals 124, 402, 422, 424 in FIGS. It may be performed by use of an interface.

  In the method of FIG. 9, step 710 in which the second kernel 104 provides the kernel service 522 includes step 712 in which the second kernel 104 provides a generic response 714 to the generic system call 704. The generic response 714 in this example is a response having a generic format 716 and a generic content 718. The generic format and the generic response are formats and content accepted as compatible by multiple kernels, including the first kernel 102 in this example.

  Embodiments of the present invention have been described extensively in the context of a fully functional computer system for sharing kernel services between kernels. However, it will be apparent to those skilled in the art that the present invention may be embodied as a computer program provided on a signal bearing medium for use by any suitable data processing system. Such signal bearing media may be transmission media or recordable media for machine-readable information, including magnetic media, optical media, or other suitable media. Examples of recordable media include magnetic disks in hard disk drives, compact disks for optical drives, magnetic tapes, and other media that may occur to those skilled in the art. Examples of transmission media include a telephone network for voice communication and a digital data communication network, such as a network that communicates using, for example, Ethernet and Internet protocols and the World Wide Web. It will be readily apparent to those skilled in the art that any computer system having suitable programming means can implement the method steps of the present invention as a computer program. Although some of the embodiments disclosed herein are directed to software that is installed and executed on computer hardware, still other embodiments implemented as firmware or as heartware are also present. It will be apparent to those skilled in the art that it is within the scope of the invention.

  It will be apparent from the foregoing description that modifications and changes may be made in the various embodiments of the present invention without departing from the spirit of the invention. The description herein is for illustrative purposes only and should not be construed in a limiting sense. The scope of the present invention should be limited only by the description of the claims.

1 is a block diagram of an automated computing machine including an exemplary computer useful for sharing kernel services between kernels in accordance with an embodiment of the present invention. FIG. 1 is a functional block diagram illustrating an exemplary system for sharing kernel services between kernels in accordance with an embodiment of the present invention. FIG. FIG. 3 is a state diagram illustrating the state of an exemplary thread for sharing kernel services between kernels, in accordance with an embodiment of the present invention. FIG. 3 is a state diagram illustrating states of an exemplary virtual processor for scheduling virtual processors in a computer system sharing a kernel, in accordance with an embodiment of the present invention. FIG. 3 is a functional block diagram illustrating a further exemplary system for sharing kernel services between kernels in accordance with an embodiment of the present invention. FIG. 3 is a functional block diagram illustrating a further exemplary system for sharing kernel services between kernels in accordance with an embodiment of the present invention. 4 is a flowchart illustrating a further exemplary method for sharing kernel services between kernels, in accordance with an embodiment of the present invention. 4 is a flowchart illustrating a further exemplary method for sharing kernel services between kernels, in accordance with an embodiment of the present invention. 4 is a flowchart illustrating a further exemplary method for sharing kernel services between kernels, in accordance with an embodiment of the present invention.

Claims (8)

A method of sharing kernel services between kernels,
A partition manager receiving a first system call from an application in a logical partition having a format and content compatible with the first kernel and seeking kernel services from the first kernel;
Generating a second system call having a format and content compatible with a second kernel and seeking kernel services from the second kernel according to the first system call;
Sending the second system call to the second kernel for execution via the partition manager. Said second kernel providing kernel services;
The method of claim 1, further comprising: sending a response having a format and content compatible with the first kernel to an application in the logical partition. Receiving the first system call by the first kernel;
The first kernel determining that the kernel service is to be provided by the second kernel; and
The method of claim 1, wherein generating the second system call comprises causing the first kernel to generate the second system call according to the first system call.   The method of claim 1, wherein generating the second system call generates a general system call.   The method of claim 1, further comprising providing a kernel service, the second kernel comprising providing a generic response to the second system call.   The second kernel further comprising providing a kernel service, including providing a response to the second system call to the first kernel, wherein the response is compatible with the first kernel; The method of claim 1, further comprising: An apparatus for sharing kernel services between kernels, comprising a computer processor and computer memory connected to the computer processor, the computer memory comprising:
Computer program instructions for a partition manager to receive a first system call from an application in a logical partition that has a format and content compatible with the first kernel and that seeks kernel services from the first kernel When,
Computer program instructions for generating a second system call having a format and content compatible with a second kernel and seeking kernel services from the second kernel according to the first system call;
An apparatus storing computer program instructions for sending the second system call to the second kernel for execution via the partition manager. A computer program recorded on a signal holding medium for sharing kernel services between kernels,
A procedure for the partition manager to receive from the application in the logical partition a first system call having a format and content compatible with the first kernel and seeking kernel services from the first kernel;
In accordance with the first system call, a procedure for generating a second system call having a format and content compatible with a second kernel and seeking kernel services from the second kernel;
A computer program for causing a computer to execute a procedure for sending the second system call to the second kernel via the partition manager for execution.

Images