Get best of the week

Sistema operacional Sivelkiriya: tecnologias

Olá, Habr.

Este artigo continua a série de publicações sobre o projeto do sistema operacional Sivelkiriya. Como já mencionado em artigos anteriores, este sistema operacional está atualmente em um estágio inicial de design e desenvolvimento; portanto, aqueles que desejam obter provas terão que ser pacientes. Só para mencionar, mais uma vez, que o autor não pretende convencer ninguém de nada, continuando a publicar para se beneficiar das discussões. Aproveito esta oportunidade para expressar minha gratidão a todos que deixaram comentários úteis em publicações anteriores.

O primeiro artigo do ciclo forneceu informações breves sobre a estrutura desse sistema operacional. No segundo artigoos objetivos do projeto foram descritos, bem como como deveria sair do círculo vicioso de "sem software - sem usuários - sem desenvolvedores - sem software". Desta vez, o foco estará nas questões arquitetônicas. Será mostrado por que meios técnicos é suposto garantir a interação de módulos escritos por diferentes pessoas em diferentes idiomas e montados em diferentes ambientes. Além disso, pequenos detalhes da arquitetura serão afetados.

Executores do módulo


Para garantir o carregamento, o lançamento e a execução de módulos, o conceito de artistas é introduzido em Sivelkiriya. Os artistas em si são módulos e, em relação aos módulos que executam, assumem as seguintes responsabilidades:

  1. Download de módulos usados ​​na RAM, inicialização, finalização e descarregamento;
  2. Vincular a API fornecida pelo sistema operacional ao código executável dos módulos: garantir a passagem de chamadas e dados da API do sistema operacional para o código dos módulos e vice-versa;
  3. Faça o download e prepare o ambiente de tempo de execução exigido pelo módulo;
  4. Tradução do código do módulo de qualquer representação intermediária (código-fonte em um idioma interpretado; código de bytes; idioma intermediário; assembly destinado a outra plataforma) em uma sequência de instruções da máquina. As ações específicas nesta etapa (interpretação do script, interpretação do bytecode, compilação do JIT, emulação etc.) são determinadas pelo método de entrega do módulo;
  5. Ocultando a maneira como o módulo funciona a partir do sistema operacional e de outros módulos.

Além disso, o executor pode assumir a tarefa de isolar os dados de vários módulos se a coexistência de dois ou mais módulos no mesmo espaço de endereço não representar um risco de segurança (por exemplo, para código gerenciado), e o trabalho do próprio executor é tão estável que há erros no carregamento. eles módulo não levará a problemas no trabalho do contratante e outros módulos servidos por ele.

Esse conceito permite o uso de vários métodos para montar módulos em um sistema comum. Por exemplo, o código de máquina obtido pela compilação do código C ++ será carregado por um executor que suporta a execução direta em um espaço de endereço separado e vinculado ao ambiente de tempo de execução necessário. O código IL gerenciado pode ser carregado por um executor que suporta a execução do código gerenciado; além disso, o isolamento pode ser realizado no nível do sistema operacional (carregando vários módulos em diferentes espaços de endereço) e no nível do executor (carregando vários módulos em um espaço de endereço comum, mas em diferentes domínios do ambiente).

Uma exceção é o caso de executar o código da máquina no Sivelkiriya, que é executado como parte do sistema operacional principal como um conjunto de bibliotecas e / ou processos. A execução direta do código da máquina nessas condições é permitida apenas se a ausência de chamadas do código da máquina para o sistema operacional principal ignorando Sivelkiriya for garantida ou se essas chamadas forem necessárias do ponto de vista do sistema. Por exemplo, essa condição pode ser atendida em um ambiente corporativo controlado, bem como em projetos de código aberto. Por outro lado, os módulos que acessam os recursos do sistema operacional principal, por definição, precisam de uma maneira de chamar suas funções. Se a "limpeza" do código da máquina não puder ser garantida, esse código poderá ser executado no modo de emulação (assim como o código compilado para outra plataforma).

Se o Sivelkiriya for lançado como o sistema operacional principal, a separação dos espaços de endereço no nível do SO será realizada por seu núcleo. Se for executado como um conjunto de bibliotecas ou processos no sistema operacional principal, para garantir o isolamento, diferentes módulos poderão ser carregados em diferentes processos do sistema operacional principal. Os módulos do sistema responsáveis ​​pelo trabalho direto com o equipamento (por exemplo, drivers do sistema de arquivos), no caso de iniciar no sistema operacional principal, serão substituídos por módulos que imitam esse comportamento, ocultando assim as diferenças dos módulos do aplicativo.

O ambiente de tempo de execução mencionado acima, específico para uma linguagem e compilador específicos, é a primeira de duas exceções à regra que exige troca de dados entre todos os módulos apenas através das interfaces de objeto do sistema, pois é necessário carregá-lo no espaço de endereço do módulo para sua operação. O conceito de bibliotecas vinculadas dinamicamente usadas por vários módulos geralmente não é suportado em Sivelkiriya, pois visa implementar o compartilhamento de código, que já está sendo implementado por meio de interfaces de módulo.

A segunda exceção é a permissão para usar bibliotecas vinculadas dinamicamente a vários módulos que são entregues juntos no mesmo pacote. Ao mesmo tempo, Sivelkiriya não oferece a oportunidade de conectar a mesma biblioteca a outros módulos, bem como os subsistemas para pesquisar bibliotecas dinâmicas.

Quando o sistema é inicializado, parte dos artistas é carregada na memória ao mesmo tempo que o kernel, para evitar a situação em que outro artista é necessário para carregar o artista, que também ainda não foi carregado. Isso se aplica, antes de tudo, aos executores que fornecem o lançamento do código da máquina nesta plataforma. Os artistas restantes são carregados na memória de acordo com as regras gerais.

Outras soluções arquitetônicas


A seguir, é apresentada uma breve lista não estruturada de princípios secundários para a construção da arquitetura do Sivelkiriya OS. Eles não são tão importantes quanto os princípios básicos descritos acima, mas merecem ser mencionados.

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


A primeira publicação do ciclo está disponível aqui . O segundo está aqui . O quarto está aqui . O texto completo do artigo está disponível no site do projeto .

More articles:


All Articles