Operating system architecture supported by microkernel generation

Abstract

The present invention relates to computer operating systems and proposes a novel OS architecture to provide compatibility between different generations of user applications and operating systems. In addition, the OS also implements a refined module-based structure for customization and full access to hardware functions. The OS and its kernel can be developed for new functions and hardware without damaging and rewriting existing software components and applications. This architecture is represented as ACOM - an evolving COM component architecture with invariant interfaces and their specifications, allowing components to freely program code implementations. It includes: the modular microkernel itself, the possibility for the OS to run containers of microkernels of different generations simultaneously, including / delegating or aggregating other required components; a special marshaling mechanism that reduces the size of headers by allowing executable files to have address pointers for a single system interface instance for dynamic function imports, without the need to recompile earlier executable files in an application according to the latest version of the OS system library.

Description

Technical Field

[0001] The present disclosure relates to computer engineering, and more particularly to an operating system (OS) architecture that provides for the concurrent operation of microkernels of various generations. Background Art

[0002] Most modern operating systems are well-structured modular systems that are capable of being developed, extended, and transferred to new hardware platforms. One of the structural choices for an OS is the distinction between a monolithic architecture and a microkernel architecture.

[0003] The kernel is the central part of the operating system that provides coordinated access to computer resources such as processor time, memory, external hardware, and input and output peripheral devices to applications. The kernel typically provides file system and network protocol services. A microkernel (μ-kernel) is an operating system kernel with a minimal set of functions.

[0004] Microkernels are conditionally divided into multiple generations. Microkernels of each generation differ in structure and solutions.

[0005] Currently, there are many solutions that describe OS architectures.

[0006] There is a known prior art solution for describing a computer operating system (US2006282899A1 published by Microsoft Corporation on December 14, 2006). The disadvantage of this solution is that elements of the kernel itself cannot be changed, and functions can only be added at the kernel and application levels.

[0007] There is a known prior art solution for describing a computer operating system that includes multiple various components (US6075939A published by LYNXREAL TRIME SYSTEMS INC on June 13, 2000). In this known solution, the components include function input and output tables. The disadvantage of this solution is that it does not provide the interchangeability of any architectural components.

[0008] There are many known solutions that describe various OS architectures. For example, such solutions are disclosed in the following documents: US20100251265A1, US20090158299A1, US20080148277A1, US6308247В1.

[0009] However, the prior art OS architecture solutions have reduced functionality. In particular, none of them can provide for the concurrent operation of microkernels of various generations. Summary of the Invention

[0010] The technical problem to be solved by the present invention is to create an operating system architecture that provides for the concurrent operation of microkernels of various generations, which is described in the independent claims.

[0011] The technical result is the creation of an operating system architecture that can run microkernels of different generations simultaneously. It provides the option to run system components and applications developed for microkernels of different generations (various operating system versions), and provides the option to more widely use the platform hardware resources by developing the OS kernel without compromising the existing application software functions.

[0012] An additional technical result obtained by solving the technical task is the provision of microkernel OS modularity; the modular principle allows components to be started and stopped as needed; for example, to correct an error, the component code can be changed, a new component can be compiled, the old component can be stopped, and the new component can be started.

[0013] The preferred embodiment provides an operating system (OS) architecture configured to run microkernels of different generations simultaneously, including:

[0014] A set of interconnected components of an Adapted Component Object Model (ACOM) with a modular structure; the ACOM group includes one or more components of each type selected from the following groups:

[0015] · A management component configured to provide access to and control of computer system resources;

[0016] · A display component configured to control the display of the user interface;

[0017] · An application component configured to execute the logic of the applied tasks;

[0018] · A microkernel component made as a container, which internally contains:

[0019] a. A scheduler component configured to set and run tasks;

[0020] b. A component of the interface bus configured to perform tasks of loading, registering, and configuring interfaces of components;

[0021] Wherein, the header of each component includes an interface table, which includes: a system interface pointer for accessing the loaded components and their function interfaces, and a component factory interface pointer configured to register the component in the interface bus and access the component interface;

[0022] Wherein, the modular structure runs multiple microkernels simultaneously in the same OS instance; according to the hardware options, each new microkernel generation includes the previous microkernel generation through an inclusion or aggregation mechanism. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Embodiments of the present invention will be described below with reference to the drawings presented for explaining the essence of the present invention, and will in no way limit the scope of the present invention. The following drawings have been attached to this application:

[0024] Figure 1 Shows the OS architecture.

[0025] Figure 2 Shows the microkernel architecture.

[0026] Figure 3 Shows a new generation of microkernel including the previous generation of microkernel.

[0027] Figure 4 Shows the loading process of microkernel components.

[0028] Figure 5 Shows an example of a component reuse mechanism.

[0029] Figure 6 Shows an example of round-robin scheduling.

[0030] Figure 7 Displays the general executable file format. Detailed Description of the Invention

[0031] In the following detailed description of the embodiments of the present invention, multiple embodiment details are provided to provide a clear understanding of the present invention. However, for those skilled in the art, the usage of the present invention is obvious regardless of whether there are embodiment details. In other cases, well-known methods, steps, and components are not described in detail to avoid obscuring the specific features of the present invention.

[0032] In addition, it is obvious from the given description that the present invention goes beyond the described embodiments. Various possible modifications, changes, variations, and substitutions to maintain the essence and form of the present invention are obvious to those skilled in the art.

[0033] The present invention aims to create an OS architecture that provides simultaneous operation of microkernels of each generation.

[0034] The microkernel is responsible for implementing the following functions:

[0035] 1) Process scheduling - One of the microkernel components is a scheduler for selecting one of the started process controls to transfer to; includes a synchronization mechanism;

[0036] 2) Delegate interrupt processor - All hardware interrupts and exceptions are transferred to their respective registered processes to handle one or another interrupt without microkernel interference, except for events that are provided by the microkernel and have been registered (e.g., the timer interrupt processor used by the scheduler);

[0037] 3) Inter-process communication - The interface bus is used to provide communication between processes by requesting one or another interface and registering for events of one or another interface.

[0038] In the claimed solution, the OS architecture is based on ACOM. The OS architecture includes multiple interconnected ACOM components that have a modular structure and support microkernel operations across generations. The components are part of a distributed application. The modular principle allows components to be run and stopped as needed, for example, to correct errors, the component code can be changed, a new component can be compiled, the old component can be stopped, and the new component can be started.

[0039] All basic OS elements, including its microkernel, consist of components with interaction interfaces. The microkernel itself is also a component with an interface. In the claimed ACOM technology, there are component reuse mechanisms: aggregation and containment, for reusing old microkernel versions in new microkernel generations.

[0040] ACOM is based on the evolving concept of Microsoft COM technology.

[0041] In the claimed solution, the operating system architecture that provides microkernel generation support is based on the following uses:

[0042] 1) The IUnknown interface with QueryInterface, AddRef, and Release methods. In ACOM, this interface is called IEcoUnknown. In known COM technology, the GUID component identifier is 128 bits, while in the claimed solution, it can be 64 bits, 128 bits, or 256 bits.

[0043] 2) The class factory. However, in ACOM, the IСlassFactory interface is called IEcoComponentFactory and is used as a component instance creation mechanism.

[0044] 3) Component reuse mechanisms – containment and aggregation. Containment and aggregation are programming techniques where one (external) component uses another (internal) component, i.e., the external component aggregates or contains the internal component. The difference between the two techniques is that in the case of containment, the external component implements the internal component interface, and thus, it can control the internal component before calling. In the case of aggregation, the external component does not implement the internal component interface but directly transfers control to the internal component. The following figure ( Figure 5 ) shows the technical differences.

[0045] These techniques, combined with the interface usage concept (virtual function table), provide options for supporting the operation of microkernels across generations.

[0046] 4) The marshaling mechanism.

[0047] Contrary to the known prior art OS architectures, the proposed architecture has the following characteristics:

[0048] First, it supports multiple generations of microkernel components and can run microkernels of various generations simultaneously. Each new generation of microkernel (N+1, where N is the current generation) needs to support new hardware processor architectures, which is part of the evolution of computer engineering and technological development. It can include changes in the architecture and computing logic in the CPU or controller, as well as changes in the number of bits provided, programs, and I / O interfaces. To support such changes at the OS level, new generations of microkernels are developed. When starting an application developed for a specific processor architecture (and thus for a specific microkernel generation), the OS will verify the loaded components; if not available, it will load the required microkernel into the computer memory. In this case, the loaded N-generation microkernel will register a pointer to itself with the N+1 microkernel running in the OS (if started) or a later N+M microkernel. The fact that multiple generations of microkernels can run simultaneously in the same operating system instance allows any application developed for various platform architectures (and thus various OS microkernels) to be used simultaneously. After releasing a new OS version (generation), it does not lose compatibility and operability with older applications, thus saving the investment of software developers as well as end-users, and separately solving the problem of application software incompatibility caused by new alternative OS versions and changes in program interfaces and kernels in purchasing new software versions.

[0049] The second remarkable feature is that the microkernel components themselves have the form of a container, consisting of components such as a scheduler component and an interface bus component, which can use various implementations of internal components according to the required OS tasks and operating modes. For example, it is possible to choose to switch to the real-time mode or other specific implementations of the scheduling mechanism or resource access allocation.

[0050] According to Figure 1 , the claimed OS architecture (100) is constructed according to the client-server mode using ACOM technology. All OS architecture elements, including the microkernel ( Figure 2 ), are components. Each component has a specification with an interface description, and the interface description in turn allows one or another architecture element to be implemented independently according to the specification. Based on the modular principle, the architecture is component-based, thus allowing only the necessary components (modules) to be included in the OS according to the set tasks. Due to the component reuse mechanism: under ACOM aggregation and inclusion, a new generation of microkernel may contain the previous generation of microkernel ( Figure 3 ). The component reuse mechanism applies to the entire component-based OS architecture constructed according to ACOM technology.

[0051] The ACOM group contains one or more components of each type selected from the following groups:

[0052] · Management components configured to provide access to and control of computer system resources;

[0053] · A display component configured to control the display of the user interface;

[0054] · An application component configured to execute the logic of the applied tasks;

[0055] · A microkernel component made as a container, which contains internally:

[0056] a. A scheduler component configured to set up and run tasks;

[0057] b. An interface bus component configured to perform the tasks of loading, registering, and configuring interfaces of components;

[0058] Wherein, the header of each component includes an interface table, and the interface table includes: a system interface pointer for accessing the interfaces of the loaded components and their functions, and a component factory interface pointer configured to register the component in the interface bus and access the component interface. The modular structure can run multiple microkernels simultaneously in the same OS instance. According to the hardware options, each new generation of microkernels includes the previous generation of microkernels through an inclusion or aggregation mechanism.

[0059] Figure 4 Shows the loading process of the microkernel component.

[0060] The system loader is a system component directly dependent on the hardware.

[0061] In the lowest configuration, the loader loads the system microkernel and the "boot application".

[0062] As an option, the loader can load the following components:

[0063] - Memory manager;

[0064] - Device manager;

[0065] - File manager;;

[0066] - Custom components.

[0067] After loading the microkernel into the memory, the loader registers the loaded components (such as the memory manager, device manager, file manager, and custom components) in the interface bus according to the linkage situation. Then, the loader loads the "boot application", whose task context is stored in the scheduler and transfers the control to it. Thus, the OS startup process is completed. Then, the boot application can create and manage tasks.

[0068] According to the task type, the "boot application" can be used as an independent execution unit or as a shell for generating processes.

[0069] The loading stage of the lowest OS configuration is as follows:

[0070] - After power-on, the basic boot process will start to search for and read the boot sector, and then the process will transfer control to the boot sector program.

[0071] - Depending on the type of file system, the program located in the boot sector will load the main OS loader located on the file system into the available storage area and transfer control to the loader.

[0072] - The OS loader is a program that implements the OS loading scenario according to the components for the initial run of the startup application. One implementation of the OS loading scenario is to use an interactive menu that is used to select components in the file system.

[0073] - In the first step, the OS loader loads the microkernel components. The loader can load the components into any available memory area according to the scenario and initialize (prepare to run) them through the microkernel component interfaces described in the specification (such as stack size, memory area, etc.).

[0074] - In the second step, the OS loader loads the scheduler component. The loader can load the scheduler component into any available memory area according to the scenario.

[0075] - In the third step, the OS loader loads the interface bus component. The loader can load the interface bus component into any available memory area according to the scenario.

[0076] - After successfully loading the microkernel components (such as the scheduler and interface bus), the loader initializes the scheduler and interface bus components in the microkernel by calling the microkernel interface initialization method and passing pointers as parameters to the scheduler and interface bus components.

[0077] However, it should be emphasized that since the microkernel components and the scheduler and interface bus components have interfaces described in the specification, any developer can make their own implementation according to the specification, whether it is the microkernel, the scheduler, or the interface bus component. For example: An independent developer has developed a scheduler in which the process switching time is reduced by several cycles of the processor time. However, this component has the interface described in the specification. Therefore, the scheduler component developed by the independent developer can be set to be loaded in the OS loading scenario.

[0078] - The next step in the operating system loading scheme is to load and register in the interface bus of the optional components that are essential for starting the application. This step is not required and depends on the components used by the startup application. Take one of the components with the highest demand - the memory management component as an example. Depending on the situation, the loader can load the memory management component into any available memory area.

[0079] - After successfully loading the optional components, the OS loader calls the registration method of the interface bus component interface to register the components in the system.

[0080] However, it should be emphasized that in most operating systems, memory management is an integral part of the operating system. A significant feature of the claimed OS architecture is that due to various memory allocation methods, memory management is an optional task: - It does not involve external memory (fixed partitioning, dynamic partitioning, relocatable partitioning), and it involves external memory (paging, segmentation, or paging and segmentation). From this perspective, the memory management component specification describes the interface requirements but does not specify the memory allocation method. Therefore, memory management component developers can use the memory management method that they consider to be the most effective. In the claimed OS architecture, immutable interfaces (input and output parameters) and strict implementation according to the specification are very important.

[0081] The interfaces of components located in memory or the file system are called through the interface bus component.

[0082] After loading the microkernel into memory, the loader registers the loaded system components, such as the memory management component, device manager, file manager, etc., on the interface bus according to the link scenario.

[0083] However, it should be emphasized that the interface bus component registry only contains data on components located in memory. The registry capacity for component registration is limited. To expand the interface bus registry, it is necessary to load the memory manager, which is executed by the loader when the microkernel is loaded and registered in the interface bus registry. Components located in the file system are loaded through the file manager. In the case of using components located in the file system, the loader must load the file manager into the system memory and register it in the interface bus registry.

[0084] Regarding the scheduler component, it also has an interface described according to the specification, which provides a set of schedulers with various characteristics (with various scheduling algorithms) according to tasks.

[0085] For example, the scheduler can be implemented using the time-slot algorithm to achieve the simplest task scheduling. Processor time slots are allocated to each task. When the time slot ends, the scheduler places the task at the end of the queue (as Figure 6 shown).

[0086] The OS executable file format is described as follows.

[0087] The usual executable file format is as Figure 7As shown. The header contains general information about the file and its basic characteristics. The interface table contains pointers to the IEcoUnknown interface addresses. The main pointer (link) is a pointer to the system interface (EcoSystem1); this interface provides access to imported components and their method (function) interfaces. The second important pointer in the interface table is the pointer to the component factory interface (IEcoComponentFactory); through this interface, the system registers components in the interface bus and creates data instances. The interface table is followed by specific operating system headers, code, and data blocks (segments).

[0088] A notable feature of the format is the absence of function import and export tables, which greatly reduces the capacity of the executable file header. Due to continuous development, improvement, and addition of new features, the microkernel OS shell creates an instance of the latest version of the system interface at one or another stage of the loading process.

[0089] Since the interface table contains pointers to the IEcoUnknown interface addresses, the OS shell (especially the system interface) will write the pointer addresses, such as the IEcoSystem4 of the 4th version of the system interface.

[0090] An executable process that uses the QueryInterface method of the IEcoUnknown interface (whether it is an old version or the latest version, developed for the first version of the kernel using the IEcoSystem1 system interface or for the latest version of the kernel using the IEcoSystem4 system interface) calls the version of the system interface it can use. For the first case, the IEcoSystem4 system interface will create an instance of the IEcoSystem1 system interface and return the corresponding pointer. For the second case, IEcoUnknown will return a pointer to itself because the IEcoUnknown interface address is the same as the IEcoSystem4 address.

[0091] Therefore, the operability of programs developed earlier is supported in the latest OS version at the binary level, that is, no recompilation is required.

[0092] As a comparison, a simple "Hello World!" program written for the 2.x kernel RedHat OS version using the printf function of the libc library cannot run on the 3.x kernel RedHat Os version without recompilation and will display an error "libc2.x library not found".

[0093] Another prominent feature provided by the above interaction mode is that applications (processes) developed for the latest OS version can resolve their minimum functionality and can run (execute) on earlier OS versions. In other words, if a process (using the QueryInterface method of the IEcoUnknown interface) calls the IEcoSystem4 system interface and returns a null pointer, the process can call a pointer to an earlier system interface version, such as IEcoSystem3, which limits its capabilities respectively. No operating system in the prior art uses this method at the executable file level.

[0094] Therefore, an advantage is achieved at the executable file level:

[0095] 1) The imported function has only one system interface pointer address;

[0096] 2) There is no need to recompile earlier software versions according to the latest version of the OS system library;

[0097] 3) Software developed for the new OS version can be executed in a reduced functionality mode on earlier OS versions.

[0098] The materials of this application contain preferred embodiments of the technical solution, which should not be used to limit other private embodiments, which do not exceed the required legal protection scope and are obvious to experts in the field.

Claims

1. An operating system architecture configured to run microkernels of various generations simultaneously, comprising: A set of interconnected components adapted to the Component Object Model with a modular structure; the set of components adapted to the Component Object Model includes one or more components of each type selected from the following groups: · A management component configured to provide access to and control of computer system resources; · A display component configured to control the display of the user interface; · An application component configured to execute the logic of the applied tasks; · A microkernel component made as a container, which internally contains: a. A scheduler component configured to set and run tasks; b. An interface bus component configured to perform tasks of loading, registering, and configuring interfaces of components; Wherein, the header of each component includes an interface table, and the interface table includes: a. A system interface pointer for accessing the interfaces of loaded components and their functions, and b. A component factory interface pointer configured to register components in the microkernel interface bus and access component interfaces; wherein, when the loaded executable file or component is developed for a different version of the microkernel, the current microkernel is queried to obtain the system interface of the version corresponding to the loaded file or component; then a new requested generation of the microkernel is initialized, and a system interface instance is created in the new requested generation of the microkernel and the corresponding pointer is returned; on the contrary, when the executable file is developed for the current version of the microkernel, the query will return a pointer to the system interface instance in the current microkernel; Wherein, the modular structure runs multiple generations of microkernels simultaneously in the same operating system instance; according to the hardware options, each new generation of microkernel includes the previous generation of microkernel through an inclusion or aggregation mechanism.

2. The operating system architecture according to claim 1, characterized in that, Components of the old microkernel version are reused through aggregation and inclusion in the new generation of microkernel.

3. The operating system architecture according to claim 1, characterized in that, A generation of microkernel components includes microkernel components of different generations.

4. The operating system architecture according to claim 1, characterized in that, The corresponding pointers of the created system interface instances are saved in the component memory.

5. The operating system architecture according to claim 1, characterized in that, The executable file header does not include a function import table and an export table.

6. The operating system architecture according to claim 1, wherein The operating system loader is responsible for starting the creation of new different versions of the microkernel.

7. The operating system architecture according to claim 1, characterized in that, The operating system loader queries the microkernel to obtain a new system interface instance of the loaded component.

8. A computer system, characterized in that, Comprising: At least one hardware processor configured to execute computer-readable instructions provided as part of an operating system, the operating system being configured to run microkernels of various generations simultaneously, these microkernels being configured to run with different types of hardware resources on which the operating system is configured to run, the operating system including: A set of interconnected components adapted to the Component Object Model with a modular structure, which includes a microkernel and at least one of the following: 1) A resource manager, which includes computer-executable instructions that, when executed by at least one hardware processor, are configured to provide access to and control of computer system resources, and 2) An application component, which includes computer-executable instructions that, when executed by at least one hardware processor, are configured to execute the logic of application tasks; Wherein, the microkernel includes: a) A scheduler component that includes computer-executable instructions that, when executed by at least one hardware processor, are configured to set up and run tasks; and b) An interface bus component that includes computer-executable instructions that, when executed by at least one hardware processor, are configured to load, register components, and configure interfaces; wherein the interface table includes: a) A system interface pointer for accessing the interfaces of loaded components and their functions, and b) A component factory interface pointer that is configured to register components in the interface bus and access component interfaces; wherein the operating system includes further computer-executable instructions that, when executed by at least one hardware processor, configure the at least one hardware processor to perform operations including the following: When a loaded executable file or component is developed for a different version of the microkernel, query the current microkernel to obtain the system interface corresponding to the version of the loaded file or component; then initialize a new requested generation of the microkernel, create a system interface instance in the new requested generation of the microkernel, and return the corresponding pointer; When the executable file is developed for the current version of the microkernel, query to return a pointer to the system interface instance in the current microkernel; wherein the modular structure runs multiple generations of microkernels simultaneously in the same operating system instance; depending on the hardware options, each new microkernel generation includes the previous microkernel generation through an inclusion or aggregation mechanism.

Images