O que é FKernel: O bottom layer - MicroKernel
Introdução
Dentro da computação existe o que consideramos áreas díficeis, áreas muito dificeis.
O que envolve baixissimo nível em ambientes limitados, como sistemas operacionais, embarcados … etc.
Dentre essas áreas temos sistemas operacionais que exigem controle estritamente rigoroso de coisas como gerenciamento de processos, gerenciamento de memória, sistemas de arquivos dentre outros.
E isso é necessário por diversos motivos, segurança, confiabilidade … precisamos fazer tudo da forma mais prosaica e eficiente possivel.
Invariávelmente, sempre vamos acabar de uma forma ou de outra perdidos em alguma decisão, monoliticos ou microkerneis.
Andrew Taunenbaum escolheu os micro-kerneis, Linus Torvalds escolheu os monolitos. E empresas como Microsoft e Apple ficaram no meio termo como os kerneis híbridos.
Eu particularmente quero montar um Kernel híbrido próprio clean-room (não pegar código de ninguem) mas inspirado em conceitos como os do BSD/Unix, SEL4, obviamente Redox, Minix e Linux.
Por que?
Simplesmente porque quero e porque posso.
Criar um sistema operacional usável e funcional é o sonho de qualquer dev de baixo nível. E eu consigo citar alguns exemplos famosos como o:
Quer fazer? Faça. Just Do It.
E qual seria o diferencial deste kernel para outros kerneis híbridos como NT ou XNU?
Primeiramente teriamos 3 abordagens aplicadas a este código:
Usariamos 3 linguagens principais:
- Rust para se trabalhar no micro kernel
- Fasm para ser a linguagem de montagem selecionada para o projeto
- C++ para ser a linguagem de programação no kernel monolito
E sim, eu me inspirei muito no SerenityOS e no RedoxOS para fazer essa seleção.
MicroKernel?
O microkernel é a parte mais corna desse projeto, literalmente é que vai lidar com:
E fica bem mais corno porque…
Eu sou insano de querer colocar um controlador via Finite State Machine. Junto com o uso de algoritmos deterministas que ignoram totalmente heuristicas para se tomar uma decisão. 1 vai ser 1 mesmo que o sistema diga que o sistema suporta 2 ou 4.
O FSM é aplicado por tarefa então não tem explosão de multiplas chamadas
O gerenciamento de memória é feito de uma forma que
Memória física é alocada numa mistura de:
-
Bitmap + Stack/List * Quando, a quantidade de memória é pequena ou seja não é em KiB
-
Sized Portion Schme * Quando a quantidade de memória é mediana
-
Buddy Allocation Scheme * Quando a quantidade de memória é grande
Memória virtual é alocada inspirada numa forma de:
- Tree-Based approach com foco em AVL
E fica pior que para o multi-process provavelmente eu vá ter que adicionar threads aos processos e garantir a preempção usando o algoritmo de Round Robin e usando algo como pre-allocated onde a duração dos quantums é salva dentro de um cache e é usada para definir a forma do baseado no tamanho MLFQ.
No bom, no mal e no feio. Essa ideia vai cada vez mais se complicando aos poucos. Provavelmente eu vá revisitar essa ideia do microKernel mais tarde.
Mas o IPC vai ser com total certeza inspirado nas mensagems do SEL4 e do Beam (Erlang)
Conclusão
Provavelmente eu vá revisar esse projeto algumas (várias) vezes para ver se estou fazendo da melhor forma possível.
Provavelmente a implementação:
- Vai ter verificação formal
- Infinitos testes únitários
- Asserts em runtime para evitar caminhos desnecessários na execução do código