Get best of the week

Sistema operativo Sivelkiriya: tecnologías

Hola Habr

Este artículo continúa la serie de publicaciones sobre el proyecto del sistema operativo Sivelkiriya. Como ya se mencionó en artículos anteriores, este sistema operativo se encuentra actualmente en una etapa temprana de diseño y desarrollo, por lo que aquellos que quieran obtener pruebas tendrán que ser pacientes. Por si acaso, mencionaré una vez más que el autor no se propone convencer a nadie de nada, sino que continúa publicando para beneficiarse de las discusiones. Aprovecho esta oportunidad para expresar mi agradecimiento a todos los que dejaron comentarios útiles en publicaciones anteriores.

El primer artículo del ciclo proporcionó información breve sobre la estructura de este sistema operativo. En el segundo articuloSe describieron los objetivos del proyecto y cómo se suponía que iba a salir del círculo vicioso de "sin software, sin usuarios, sin desarrolladores, sin software". Esta vez, la atención se centrará en cuestiones arquitectónicas. Se mostrará por qué medios técnicos se supone que garantiza la interacción de los módulos escritos por diferentes personas en diferentes idiomas y ensamblados en diferentes entornos. Además, pequeños detalles de la arquitectura se verán afectados.

Ejecutantes de módulos


Para garantizar la carga, el lanzamiento y la ejecución de los módulos, se introduce el concepto de intérpretes en Sivelkiriya. Los artistas mismos son módulos y, en relación con los módulos que ejecutan, asumen las siguientes responsabilidades:

  1. Descarga de módulos usados ​​en RAM, inicialización, finalización y descarga;
  2. Vincular la API proporcionada por el sistema operativo con el código ejecutable de los módulos: garantizar el paso de llamadas y datos desde la API del sistema operativo al código de los módulos y viceversa;
  3. Descargue y prepare el entorno de tiempo de ejecución requerido por el módulo;
  4. Traducción del código del módulo de cualquier representación intermedia (código fuente en un lenguaje interpretado; código de byte; lenguaje intermedio; ensamblaje destinado a otra plataforma) en una secuencia de instrucciones de máquina. Las acciones específicas en este paso (interpretación de script, interpretación de bytecode, compilación JIT, emulación, etc.) están determinadas por el método de entrega del módulo;
  5. Ocultar el funcionamiento del módulo desde el sistema operativo y otros módulos.

Además, el ejecutor puede asumir la tarea de aislar los datos de varios módulos si la coexistencia de dos o más módulos en el mismo espacio de direcciones no representa un riesgo de seguridad (por ejemplo, para el código administrado), y el trabajo del ejecutor en sí es tan estable que hay errores en la carga El módulo no dará lugar a problemas en el trabajo del contratista y otros módulos atendidos por él.

Este concepto permite el uso de varios métodos para ensamblar módulos en un sistema común. Por ejemplo, el código de máquina obtenido compilando código C ++ será cargado por un ejecutor que admite la ejecución directa en un espacio de direcciones separado y vinculado con el entorno de tiempo de ejecución necesario. El código IL administrado puede ser cargado por un ejecutor que admite la ejecución del código administrado, y el aislamiento puede realizarse tanto a nivel del sistema operativo (cargando varios módulos en diferentes espacios de direcciones) como a nivel del ejecutor (cargando diferentes módulos en un espacio de direcciones común, pero en diferentes dominios de entorno).

Una excepción es el caso de ejecutar código de máquina bajo Sivelkiriya, que se ejecuta como parte del sistema operativo principal como un conjunto de bibliotecas y / o procesos. La ejecución directa del código de la máquina en estas condiciones está permitida solo si se garantiza la ausencia de llamadas del código de la máquina al sistema operativo principal sin pasar por Sivelkiriya, o si tales llamadas son necesarias desde el punto de vista del sistema. Por ejemplo, esta condición puede cumplirse en un entorno corporativo controlado, así como en proyectos de código abierto. Por otro lado, los módulos que acceden a los recursos del sistema operativo principal, por definición, necesitan una forma de llamar a sus funciones. Si no se puede garantizar la "limpieza" del código de la máquina, dicho código se puede ejecutar en modo de emulación (así como también el código compilado para otra plataforma).

Si se lanza Sivelkiriya como el sistema operativo principal, su núcleo lleva a cabo la separación de los espacios de direcciones a nivel del sistema operativo. Si se ejecuta como un conjunto de bibliotecas o procesos en el sistema operativo principal, para garantizar el aislamiento, se pueden cargar diferentes módulos en diferentes procesos del sistema operativo principal. Los módulos del sistema que son responsables del trabajo directo con el equipo (por ejemplo, los controladores del sistema de archivos), en caso de lanzamiento bajo el sistema operativo principal, serán reemplazados por módulos que emulan este comportamiento, ocultando así las diferencias de los módulos de la aplicación.

El entorno de tiempo de ejecución mencionado anteriormente, específico de un lenguaje y compilador específicos, es la primera de las dos excepciones a la regla que requiere el intercambio de datos entre todos los módulos solo a través de las interfaces de objetos del sistema, ya que es necesario cargarlo en el espacio de direcciones del módulo para su funcionamiento. El concepto de bibliotecas vinculadas dinámicamente que utilizan varios módulos generalmente no se admite en Sivelkiriya, ya que está destinado a implementar el intercambio de código, que ya se está implementando a través de las interfaces del módulo.

La segunda excepción es el permiso para usar bibliotecas vinculadas dinámicamente a varios módulos que se entregan juntos dentro del mismo paquete. Al mismo tiempo, Sivelkiriya no brinda la oportunidad de conectar la misma biblioteca a otros módulos, así como a los subsistemas para buscar bibliotecas dinámicas.

Cuando se inicia el sistema, parte de los artistas se carga en la memoria al mismo tiempo que el kernel, para evitar la situación en la que se necesita otro artista para cargar el artista, que aún no se ha cargado. Esto se aplica, en primer lugar, a los ejecutores que proporcionan el lanzamiento del código de máquina en esta plataforma. Los artistas restantes se cargan en la memoria de acuerdo con las reglas generales.

Otras soluciones arquitectónicas


La siguiente es una breve lista no estructurada de principios secundarios para la construcción de la arquitectura del sistema operativo Sivelkiriya. No son tan importantes como los principios básicos descritos anteriormente, pero sin embargo merecen mención.

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


La primera publicación del ciclo está disponible aquí . El segundo está aquí . El cuarto está aquí . El texto completo del artículo está disponible en el sitio web del proyecto .

More articles:


All Articles