Get best of the week

Sivelkiriya Operating System: technologies

Hello, Habr.

This article continues the series of publications about the project of the Sivelkiriya operating system. As already mentioned in previous articles, this OS is currently at an early stage of design and development, so those who want to get proofs will have to be patient. Just in case, I’ll mention once again that the author does not set out to convince anyone of anything, instead continuing to publish in order to benefit from the discussions. I take this opportunity to express my gratitude to everyone who left useful comments under past publications.

The first article of the cycle provided brief information about the structure of this OS. In the second articlethe goals of the project were described, as well as how it was supposed to break out of the vicious circle of “no software - no users - no developers - no software”. This time, the focus will be on architectural issues. It will be shown by what technical means it is supposed to ensure the interaction of modules written by different people in different languages ​​and assembled under different environments. In addition, small details of the architecture will be affected.

Module Performers


To ensure the loading, launching and execution of modules, the concept of performers is introduced in Sivelkiriya. The performers themselves are modules and, in relation to the modules they execute, take on the following responsibilities:

  1. Downloading used modules into RAM, initialization, finalization and unloading;
  2. Linking the API provided by the operating system with the executable code of the modules: ensuring the passage of calls and data from the API of the operating system to the code of the modules and vice versa;
  3. Download and prepare the runtime environment required by the module;
  4. Translation of module code from any intermediate representation (source code in an interpreted language; byte code; intermediate language; assembly intended for another platform) into a sequence of machine instructions. The specific actions at this step (script interpretation, bytecode interpretation, JIT compilation, emulation, etc.) are determined by the module delivery method;
  5. Hiding the way the module works from the operating system and other modules.

In addition, the executor can take on the task of isolating the data of various modules if the coexistence of two or more modules in the same address space does not pose a security risk (for example, for managed code), and the work of the executor itself is so stable that there are errors in the loaded they module will not lead to problems in the work of the contractor and other modules served by him.

This concept allows the use of various methods for assembling modules in a common system. For example, machine code obtained by compiling C ++ code will be loaded by an executor supporting direct execution into a separate address space and linked with the necessary runtime environment. Managed IL code can be loaded by an executor supporting the execution of managed code, moreover, isolation can be performed both at the operating system level (by loading various modules in different address spaces) and at the executor level (by loading various modules in a common address space, but in different environment domains).

An exception is the case of running machine code under Sivelkiriya, which is executed as part of the main operating system as a set of libraries and / or processes. Direct run of machine code under these conditions is allowed only if it guarantees the absence of calls from the machine code to the main operating system bypassing Sivelkiriya, or if such calls are necessary from the point of view of the system. For example, this condition can be fulfilled in a controlled corporate environment, as well as for open source projects. On the other hand, modules that access the resources of the main operating system, by definition, need a way to call its functions. If the "cleanliness" of the machine code cannot be guaranteed, such a code can be run in emulation mode (as well as code compiled for another platform).

If Sivelkiriya is launched as the main operating system, the separation of address spaces at the OS level is carried out by its core. If it is run as a set of libraries or processes under the main operating system, to ensure isolation, different modules can be loaded into different processes of the main OS. System modules that are responsible for direct work with equipment (for example, file system drivers), in case of launch under the main operating system, will be replaced by modules that emulate this behavior, thus hiding differences from application modules.

The above-mentioned runtime environment, specific to a specific language and compiler, is the first of two exceptions to the rule requiring data exchange between all modules only through the object interfaces of the system, since loading it into the address space of the module is necessary for its operation. The concept of dynamically linked libraries used by several modules is not generally supported in Sivelkiriya, since it is aimed at implementing code sharing, which is already being implemented through module interfaces.

The second exception is the permission to use dynamically linked libraries to several modules that are delivered together within the same package. At the same time, Sivelkiriya does not provide the opportunity to connect the same library to other modules, as well as the subsystems for searching dynamic libraries.

When the system boots, part of the artists is loaded into memory at the same time as the kernel, in order to avoid the situation when another artist is needed to load the artist, which is also not yet loaded. This applies, first of all, to the executors providing the launch of machine code on this platform. The remaining performers are loaded into memory according to general rules.

Other architectural solutions


The following is a brief unstructured list of secondary principles for the construction of the Sivelkiriya OS architecture. They are not as important as the basic principles outlined above, but nevertheless deserve mention.

  1. , «». , , , . -, . . , , , , , , . , ; , , Bluetooth, WiFi , Bluetooth, . , (, , , ).
  2. , . , « » « ».
  3. , . , « » « » «». , , .
  4. . , « » ( , , , ), « » . , « », « », ( ) . .
  5. , , , . , , , , . - , , .
  6. ( . .) . , , , - . .
  7. ( ) , «», , , . , , , , .
  8. , , . ( , . .) . . , , .
  9. . , , . — , , , . . , : , ( ) , , .
  10. , : . , .
  11. , , , , — . « » , ( ). , . .
  12. : , , . , , . , , , .
  13. , : , , , , , , , , , . : , , SSD, — RAID- , — , . .
  14. . ( ). , , (, , ), ( ), , , WYSIWYG- , . , .
  15. : , , . , , , ( ). , , , . , , , ( , . .).
  16. , , . , « » , (, 1 ) . , , , : , (, ) , , , , , .
  17. , , (, , ). , — , , , . — (, . .): , , , , . , . , , ( «» ). , . (, ) , ( , . .). , , . , ( , , . .) , .


The first publication of the cycle is available here . The second is here . The fourth is here . The full text of the article is available on the project website .

More articles:


All Articles