Tag Archives: ISR

Sistema Operacional miniOS-0.01: Estrutura de diretórios

Voltei! Dessa vez, para começar e por enquanto, um post mais fácil, pelo menos. Vamos falar sobre a estrutura de diretórios do projeto de um sistema operacional, e o que temos que ter e onde, além de algumas dificuldades que já começou a aparecer.

Certo, vamos mostrar a estrutura de diretórios no geral, e depois eu vou explicar o porque de cada pasta é importante e para que serve, além de levantar umas ideias gerais sobre o futuro do que vai conter em cada uma das pastas.


/src/
/src/compiler/CC
/src/kernel/boot/
/src/kernel/kpp/
/src/kernel/fs/
/src/kernel/arch/
/src/kernel/arch/ISA/
/src/kernel/arch/ISA/PLATFORM
/src/libc/
/tools/

/tools

Esse diretório é o que temos um carinho especial. Aqui vamos colocar as ferramentas que vão nos ajudar a desenvolver nosso sistema operacional, vão facilitar o desenvolvimento, na verdade.

Também vamos colocar alguns programas não relacionados com o kernel em si, pelo menos porque vão ser códigos tão pequenos que não precisam criar repositórios a parte para eles, sendo mas simples deixar ai mesmo.

/src

Aqui vai ficar os códigos relacionados ao kernel, diretamente ao que vai entrar no kernel. Provavelmente, tudo o que vai ser compilado e construido dentro do kernel vai ficar em alguma pasta por aqui.

Na verdade, os códigos não vão ficar aqui, mas em pastas separadas pelas suas funções, como explicado abaixo.

/src/compiler/

Aqui começamos a entrar em detalhes interessantes. Vamos começar com um pequeno conto, o de como um programa normal funciona.

Quando você inicia um programa, você já começa com a sua função main(), certo? Mas quem iniciou as suas variáveis globais? E quem configurou algumas funções? Quem criou os arquivos stdin, stdout e stderr?

Você pode argumentar que tudo isso é função das variáveis globais(por exemplo, stdin, stdout e por ai vai…), mas, isso ainda tem funções especificas que você tem que saber sobre o ambiente para funcionar. Esse tipo de função é de códigos específicos do compilador! No futuro, esses códigos que vamos precisar, vão estar nesse diretório. A medida que precisarmos, eu vou explicando o porque, para que e como vamos precisar disso, então relaxe por enquanto e aceite que precisamos.

Uma coisa a mais a se considerar é que existem vários compiladores, então para cada compilador eu vou precisar de algum código especifico. Essa parte não tem jeito, muita coisa pode ser reusada, mas infelizmente normalmente os codigos são diferentes um dos outros. Para manter separado, vamos criar um diretório também para cada compilador, como por exemplo:


/src/compiler/gcc

Para cada compilador, um diretório. O como vamos usar assim, mais para frente a gente fala(próximo post?).

/src/kernel/

Vamos colocar aqui os códigos especificamente feitos para o kernel. Aqui vai ficar a lógica do kernel e coisas que tem a ver com arquitetura.

/src/kernel/boot/

Precisamos de alguns códigos para inicializar o kernel. Aqui é que ficam esses códigos, aqui é a cola entre o gerenciador de boot e o seu kernel, digamos que a interface, a passagem.

Não confundir com o gerenciadores de boot, que inicializa e carrega o kernel. Isso não é trabalho de um kernel, e não vamos fazer um, então deixa essa parte quieto.

/src/kernel/kpp/

Não podemos contar com nada, ou com muito pouco pelo menos, no desenvolvimento de um kernel. Isso quer dizer que não podemos usar as bibliotecas padrões que normalmente usamos, e isso quer dizer que vamos precisar reimplementar algumas coisas.

Para todas essas coisas que iremos reimplementar de algoritmos básicos(como vector, lista, etc…), vamos colocar nesse diretório.

Sobre o nome do diretório, é as iniciais de kernel plus plus, meio sem sentido mais com sentido…

/src/kernel/fs/

Nada de novo aqui, apenas vai ser o diretório com códigos relacionados ao sistema de arquivo.

Mais no futuro a gente resolve o que vai colocar aqui, principalmente porque não sabemos ainda como vai ser a cara de como lidar com sistema de arquivos.

/src/kernel/arch/

Com certeza vamos precisar utilizar algum código que seja especifico para alguma plataforma, e nesse diretório é que vamos colocar esses códigos que vão depender de alguma arquitetura.

O objetivo é que todos os códigos que dependam de alguma plataforma fiquem aqui, basicamente como eu quero isolar o código em ASM também, gostaria que todos os códigos ficasse aqui.

Mas não é sempre que podemos isolar o código ASM do código em C/C++. Existem alguns códigos de inicialização e alguns outros códigos que precisam ser escritos em ASM para serem mais portáveis ou funcionarem como você quer.

/src/kernel/arch/ISA

Dentro dos códigos mais específicos e em ASM da arquitetura, ainda temos códigos que dependem das informações especificas da ISA da maquina. Essas declarações e códigos vão ficar aqui.

Aqui vai ficar uma parte um pouco chata do trabalho já que também vamos lidar possivelmente com C, que é construir alguns tipos da ISA. pode ser que usemos algumas soluções mais com cara de C++, mas vai ser difícil…

Também temos que ter uma forma de escolher a ISA em que nosso sistema estará compilando. Isso vai fazer parte do sistema de build.

Uma coisa importante a se ressaltar é que o nome “ISA” no nome da pasta vai ser substituído pelo nome da ISA que você esta implementando, porque você pode ter varias implementações. Por exemplo, se você estiver implementando a ISA da arquitetura x86, a pasta seria:


/src/kernel/arch/x86

Isso tudo porque depois vamos usar isso para identificar e configurar a plataforma para onde vamos gerar o nosso kernel.

/src/kernel/arch/ISA/PLATFORM

Aqui ficaram códigos ainda mais específicos das plataformas, como na ISA, só que menos genéricos ainda e mais dependentes do hardware.

É meio difícil de explicar, e fica meio nebulosa a fronteira entre os códigos da ISA e os da plataforma, mas acho que é legal criar essa divisão para aproveitar códigos usados entre plataformas. Talvez seja trabalho demais para pouca coisa também, mas nesse momento não estou ligando para isso.

Assim como no caso da ISA, se estivermos por exemplo implementado a plataforma i386 da ISA x86, faríamos:


/src/kernel/arch/x86/i386

/src/libc/

Uma das piores coisas de se contruir um sistema operacional é que você não tem acesso a praticamente nenhuma ferramente pronta. Isso quer dizer que você mal pode contar com o seu compilador, imagine as bibliotecas basicas de C ou C++.

Para facilitar esse trabalho, de reimplementar todas as bibliotecas, você pode portar algumas bibliotecas. Como a biblioteca basica de C é muito importante, é aqui que teremos os ports de algumas bibliotecas para o nosso sistema.

Porque uma pasta só para isso? Porque o ideal é que possamos trocar a implementação de forma mais fácil, então aqui dentro terremos varias opções que poderão ser escolhidas pelo sistema de build do nosso kernel.

Fim!

Bom, basicamente seria isso ai, essa vai ser a estrutura de diretórios que já adianta alguma coisa para saber o que vamos fazer.

Entrei em vários pontos aqui, mas não falei como eles serão resolvidos, algumas partes porque eu realmente vou explicar melhor isso no futuro, outras porque ainda quero descobrir a melhor forma de resolver.

Mas o mais importante é, se alguem ler isso aqui e alguma duvida surgir, perguntem aqui nos comentários, que eu vou aprimorando cada vez mais o post e também vou tentando responder as duvidas. Tentem não ser tão ansiosos e se concentrar no post de agora!


Sistema Operacional miniOS-0.00: Começando a fazer um do zero, o vai ser preciso?

Construindo um Sistema Operacional

Olá amiguinhos! Recentemente, eu comecei e terminei de construir um sistema operacional. OK, eu me orgulho disso, achei ele muito bem feito, mas ainda tem muitos pontos que eu vi que eu podia melhorar.

Então, agora, eu começo uma serie de posts em que eu pretendo refazer esse sistema, dessa vez muito mais organizado, comentando aqui no blog com posts explicando cada passo, comentando o código de forma realmente legal e inserindo alguns elementos a mais também, tudo isso com a opinião de vocês meus leitores.

Eu pretendo evoluir as ideias que eu já usei e/ou usar algumas ideias melhores que eu tinha pensado na época, mas como eu tinha tempo a cumprir eu não fiz. Além que também eu vou tentar refatorar muito do código que eu já tinha usado.

O plano de release

Como eu já fiz uma vez e tenho alguma noção, eu sei mais ou menos o caminho em ordem do que fazer, e em cada post eu vou tentar abordar cada um desses tópicos. Pelo menos esse é o plano…

Lista do que vou desenvolver em provável ordem:

  1. Estrutura de diretórios
  2. Configuração do Ambiente
  3. Build automatizado
  4. Linker
  5. Código ASM de inicialização
  6. Código “C” de inicialização
  7. Monitor
  8. kprintf
  9. Teste?
  10. Construtores globais
  11. Destrutores globais
  12. Biblioteca padrão “C
  13. Gerencia de memoria no final do kernel
  14. Algumas estruturas de dados
  15. Global Descriptor Table (GDT)
  16. Interrupt Descriptor Table (IDT)
  17. Interrupt Service Routines (ISR)
  18. Interrupt ReQuest (IRQ)
  19. Programmable Interval Timer (PIT)
  20. Teclado
  21. Interface para sistema de arquivo genérica
  22. Gerencia de memoria com paginação
  23. Multiprocesso
  24. Tratamento de Exceções?

Lembrando que provavelmente eu vou alterar esse lista com o tempo, porque eu posso mudar de ideia com relação a ordem ou posso quebrar em mais de um tema esses tópicos, coisas assim.

A parte que eu inicialmente acho mais difícil

Testes, esse é a parte realmente nova e que pode levar tempo. Requer que eu crie mais coisas também.

Testes influenciam o desenvolvimento depois, porque a arquitetura de testes influencia muito no desenvolvimento.

A complexidade é grande, e eu vou abordar melhor o porque no post sobre testes, em que eu devo resolver e propor alguma coisa.

O começo, algo feito

Como eu sempre gosto de deixar algo sempre pronto, com bônus inicial eu já criei o repositório para quem quiser ir acompanhando, no github.

Na verdade, é o repositório antigo que eu tinha feito, mas eu deletei(criei um branch, na verdade…) e recomecei do zero. Mas quem quiser já pode ir acompanhando, mas acho melhor que vocês falem comigo por aqui e vejam os posts aqui também ;).


Bom material sobre interrupções(8259) e DMA(8237)

Uma recomendação…

Ultimamente, eu tive que fazer um trabalho para falar sobre interrupções(8259) e DMA(8237), e eu achei esse excelente material que pode ajudar a guiar quem precisar:

PDF icon

O material explica muito bem como funciona os microcontroladores 8259 e 8237, muito bem especificado como em nenhum outro canto. Tem modos de operação, desenhos fáceis de entender dos circuitos, passos a passos práticos, e fala da parte de hardware e também da parte de software, muito bom para compreender em qualquer nível o que você quer.

Recentemente, eu estava trabalhando em meu próprio sistema operacional. Na construção de um S.O., você precisa entender o funcionamento da parte de software do IRQ e como usá-lo, de forma organizada também. Lendo esse documento, eu pude ter uma visão melhor do funcionamento, uma compreensão melhor do que acontece por baixo.

Com certeza, quando eu for refazer meu S.O. para reorganizar, melhorá-lo e acompanhar postando no blog, eu vou reler esse PDF para reimplementar alumas partes.

Sobre o meu trabalho…

Sobre o trabalho que eu fiz, pensei até em disponibilizar, mais o que eu fiz não ficou tão bom para justificar isso, e o professor foi meio mal, porque ele pediu para fazer o trabalho escrevendo a mão…

Isso mesmo, escrito a mão. Em pleno “seculo” 21, feito a mão. E ele assumiu que era para dar trabalho para a turma, nada a mais do que isso… Muita preocupação e esforço desperdiçado, escrever coisas não faz mais sentido.

Fica ai a minha revolta, realmente fico com raiva de ter esforço inútil.


%d bloggers like this: