Show HN: Desenvolvendo meu próprio kernel de OS que roda DOOM

 (github.com/UnmappedStack)
1 pontos por GN⁺ 2025-04-26 | 1 comentários | Compartilhar no WhatsApp
  • TacOS é um OS hobby UNIX-like baseado em um kernel próprio, escrito do zero em C e Assembly, capaz de executar DOOM e vários pequenos programas em espaço de usuário
  • O kernel inclui VFS, escalonador, TempFS, dispositivos, troca de contexto, gerenciamento de memória virtual, alocação de frames de páginas físicas e um port de Doom
  • O ambiente de execução oferece suporte tanto a hardware real quanto ao emulador Qemu; o hardware real foi testado no notebook do criador
  • A compilação e execução começam com git clone seguido de make run, e exigem Xorriso, Qemu, NASM e Clang instalados
  • TacOS não tem maturidade para uso real; é um toy OS hobby com vários bugs conhecidos

Visão geral do TacOS

  • TacOS é um OS escrito do zero em C e Assembly, com kernel próprio
  • É composto por um kernel UNIX-like e consegue executar DOOM e vários pequenos programas em espaço de usuário
  • Os principais componentes são:
    • VFS
    • escalonador
    • TempFS
    • dispositivos
    • troca de contexto
    • gerenciamento de memória virtual
    • alocação de frames de páginas físicas
    • port de Doom

Ambiente de execução e limitações

  • TacOS pode ser executado em hardware real e no emulador Qemu
  • Os testes em hardware real foram realizados no notebook do criador
  • O projeto não é um OS completo e pronto para uso real, mas sim um toy OS hobby
  • Há vários bugs conhecidos

Início rápido

  • A compilação e execução podem ser feitas com os comandos abaixo
git clone https://github.com/UnmappedStack/TacOS
cd TacOS && make run
  • make run compila o TacOS e o executa automaticamente no emulador Qemu
  • As ferramentas necessárias são:
    • Xorriso
    • Qemu
    • NASM
    • Clang

Comandos de build

  • make run: compila o TacOS e o executa no Qemu
  • make qemu: executa no Qemu um TacOS já compilado
  • make disk: gera a imagem de disco completa como tacos.iso
  • make kernel: compila o kernel do TacOS, o núcleo do sistema
  • make libc: compila a biblioteca padrão
  • make userspace: compila as aplicações em espaço de usuário
  • make initrd: cria o ramdisk inicial que o sistema usará para inicializar
  • make lint: executa as regras de linter para o kernel
  • make qemu-gdb: executa o TacOS no Qemu com o GDB conectado

Depuração

  • Para anexar o GDB durante os testes do TacOS, execute make qemu-gdb e, em outro terminal, conecte-se ao alvo remoto do GDB
$ gdb -q
(gdb) target remote :1234
(gdb) file kernel/bin/tacos
(gdb) continue
  • Ao depurar o kernel, especifique kernel/bin/tacos
  • Ao depurar programas em espaço de usuário, especifique initrd/usr/bin/<program>

Licença e regras de contribuição

  • TacOS usa a Mozilla Public License 2.0
  • Contribuições são abertas, mas antes de um pull request é necessário abrir uma issue e receber a atribuição das mudanças
  • Pull requests contendo apenas correções simples de typos ou gramática não serão aceitos
  • As mensagens de commit devem seguir o formato [component] change
  • Pull requests que agrupem milhares de linhas de alterações em vários componentes não relacionados em um único commit gigante não serão considerados para revisão

Comunidade

  • Há um servidor no Discord para atualizações sobre o TacOS, ajuda com projetos de OSDev e conversas

Leituras relacionadas

1 comentários

 
GN⁺ 2025-04-26
Opiniões no Hacker News

  • Parabéns! Imagino que você esteja orgulhoso, e também gostei da escolha de DOOM como prova de conceito.
    Talvez seja meio desanimador eu só ter perguntas de iniciante, mas fiquei curioso sobre quais seriam os passos necessários para rodar isso em um notebook.
    Depois de compilar, é um processo parecido com configurar dual boot em um PC com Windows? É meio engraçado eu estar perguntando a um desconhecido da internet como executar um software perigoso no meu computador.
    Também queria saber se há algum livro ou material de leitura que você recomendaria para quem quiser tentar um projeto desses. Na faculdade, cursei sistemas operacionais e disciplinas relacionadas, mas, como minha formação é em engenharia elétrica/eletrônica, tudo era muito abstrato e focado em conceitos. Seria ótimo ter materiais mais concretos, e não precisa necessariamente ser x64.

    • Não desanima nem um pouco! O jeito como rodei no meu notebook foi literalmente formatar um USB com a ISO e dar boot pelo USB.
      Se você quiser escrever um kernel, recomendo começar por https://osdev.wiki, e também ler especificações relevantes, como o Intel Developer Manual, além das especificações dos drivers que você for escrever.
      Não sei muito sobre desenvolvimento de kernels que não sejam x86, mas, até onde sei, a maioria dos conceitos é a mesma, só a implementação técnica muda. Há um link para um servidor do Discord no README do projeto, e lá tem muita gente realmente inteligente que ficaria feliz em ajudar.
    • Eu também escrevi um kernel, embora ainda não esteja finalizado, e documentei todos os passos que segui. Muita gente disse que foi útil: https://0xc0ffee.netlify.app/osdev

  • Legal, mas o seu taco também roda DOOM?
    Brincadeiras à parte, é um esforço realmente elogiável, ótimo trabalho! Minha dúvida é se, ao criar o TacOS, você tratou DOOM como uma meta padrão, ou se desde o início o objetivo era criar um sistema operacional dedicado só para rodar DOOM.
    Pergunto por pura curiosidade. Uns quase 30 anos atrás, fiz um sistema operacional extremamente esquelético, que basicamente só dava boot, por aprendizado e diversão; um sistema operacional dedicado, portável para qualquer lugar e capaz praticamente só de rodar DOOM, tornaria o meme “roda DOOM?” ainda mais irônico e divertido.
    Trabalho incrível, espero que continue.

    • Ele não roda só Doom; esse foi apenas o marco mais recente que portei.
      Fazer o Doom em si rodar levou cerca de uma semana, incluindo adicionar os requisitos de libc, e houve muito mais trabalho de base antes disso.
      Usei o DoomGeneric, que é basicamente um fork do Doom feito para ser muito portável. Espero que isso responda à pergunta, embora eu talvez tenha entendido errado.

  • Ir de um kernel feito do zero direto para DOOM é o tipo de coisa que parece certificação de hacker nível máximo. Ver isso rodando em hardware real deve dar uma alegria enorme, e é muito legal.

    • Rodar em hardware real é bem gratificante. O kernel não entra exatamente direto no Doom; ele dá boot em um shell, e a partir dali é possível executar o Doom.

  • Meio tangencial, mas eu me perguntava algo parecido. Fico curioso se houve muitas tentativas de criar jogos que dão boot diretamente em hardware de PC moderno.
    Seria um modelo em que você entra direto no jogo, sem carregar um sistema operacional inteiro, parecido com consoles de gerações antigas. Para manter simples, Wi‑Fi, Bluetooth, GPU e coisas assim seriam difíceis de aproveitar sem drivers modernos, mas teclado e mouse parecem bem viáveis por meio de algo como acesso básico via BIOS. Posso estar errando a terminologia, mas espero que a ideia tenha ficado clara.

    • Não sei se foi muito usado, mas é uma abordagem conhecida e funciona. Fiz isso nos meus primeiros experimentos em assembly x86-16, mas acabei usando DOS como lançador de programas para poder usar o dosbox-staging, um emulador mais fácil de usar que o qemu.
      Se você não quiser mexer com E/S de disco, a grande limitação é ficar em 512 bytes ou menos. Na prática, você está executando o programa como o master boot record. Se precisar de mais espaço, terá que ler alguns LBAs do disco; há interrupções para isso, e o osdev tem materiais melhores sobre o assunto.
      Fora isso, a diferença entre arquivos .com, normalmente com a limitação de segmento único de 64 KB, e programas inicializáveis no estilo MBR é bem pequena.

  • Trabalho realmente incrível. Eu queria ter habilidade para fazer algo assim, mas imagino que tenha sido preciso ler muitas especificações, e essa é minha maior fraqueza.
    Talvez seja uma pergunta boba, mas, se alguém quisesse usar aceleração de GPU mesmo que de forma bem pequena, quão difícil seria criar um driver de GPU? Você acha que a documentação relacionada é boa?

    • Isso provavelmente está no extremo do desenvolvimento de sistemas operacionais, e, pelo menos para uma GPU que você possa comprar de verdade, é bem possível que nem eu conseguisse fazer.
      A GPU emulada do Qemu tem uma documentação razoavelmente boa, então talvez seja possível, mas coisas como GPUs da Nvidia são mal documentadas e, até recentemente, a documentação era completamente fechada. O Linux também sofre com esse problema, e já vi alguns desenvolvedores de sistemas operacionais hobby simplesmente aproveitarem os drivers de GPU do Linux.
      Não há muita coisa que eu marcaria como quase impossível, mas escrever um driver de GPU realmente bom para uma GPU comum é algo que, sinceramente, não acho que um dia eu consiga fazer.

  • Oi, unmapped, eu uso ThatOSDeveloper no GitHub e no Discord, e esse é meu nome de exibição. Não sabia que você tinha rodado Doom no TacOS, ficou bem legal.
    Tenho algumas dúvidas: é o Doom original? Ele está no disco ou no initramfs? E, junto com a engine que você usa, você está usando Freedoom ou o WAD shareware do Doom?

    • Como dá para ver no post, é doomgeneric, e, como dá para ver no topo desta página, houve relativamente poucas modificações.
    • Uso o DoomGeneric, um fork portável do Doom. Ele fica em um TempFS carregado a partir do initrd, e uso o doom1.wad.

  • Muito legal, mas hoje existem linguagens de baixo nível com segurança de memória; então fiquei curioso por que escolher uma linguagem insegura. Todo mundo já sabe que a maioria dos bugs de segurança tem relação com memória.
    Entendo que é um projeto hobby, mas não entendo por que não aposentar linguagens inseguras quando há alternativas melhores.

    • Principalmente porque C é muito mais simples, e, no desenvolvimento de kernel, simplicidade é tudo.
      Já usei Rust em outros projetos, mas, no desenvolvimento de kernels, sinto muito mais vontade de usar uma linguagem simples e fácil de ler do que uma linguagem segura.

  • Bem-vindo ao clube! Fiz quase a mesma coisa e gostei muito da tranquilidade de construir algo que absolutamente nunca vai virar um produto.
    https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...

  • Projeto realmente incrível! Fiquei curioso sobre como o TacOS lida com isolamento de processos e escalonamento.

    • Para memória virtual, uso paginação, de modo que cada processo tenha seu próprio espaço de endereçamento.
      Há um escalonador round-robin conectado ao driver do PIT; a cada 10 ms, o PIT gera uma interrupção e o escalonador é executado. O escalonador escolhe a próxima tarefa, salva o estado atual da tarefa anterior, troca para o novo espaço de endereçamento, troca a pilha, restaura os registradores da tarefa e então usa a instrução iretq para alternar para o modo de usuário ring 3 enquanto salta para o ponteiro de instrução.

  • Quero saber mais sobre o TacOS. Como ele gerencia a execução simultânea e segura de vários programas?