4

Pitch: Coeleo OS: um sistema operacional x64 feito do zero em Rust

De onde veio isso

Aos 8 anos ganhei um netbook de aniversário da minha tia. Sem internet em casa, minha diversão era fuçar no Paint, nos arquivos do sistema e nos DVDs do meu pai. Aos 10 veio um PC de mesa, e com ele a primeira conexão — e a pergunta que me acompanhou desde então: como se faz um sistema operacional?

A resposta que encontrei na época foi Visual Basic .NET, via YouTube. Passei dias replicando tutoriais: browsers, gerenciadores de download e "sistemas operacionais" que na prática eram só aplicações de janela. Fui longe o suficiente para arranhar Assembly e fazer um sistema dar boot e imprimir na tela:

Este é o meu sistema operacional - XW OS

Depois o interesse esfriou e parei por anos. Anos depois voltei e terminei o que comecei.

O que é

Coeleo OS é um sistema operacional x86_64 com kernel, ABI de syscalls, design system e userspace próprios. Não é distro Linux, não é clone de Windows, não é RTOS.

O que ele reaproveita é pontual e nomeado: Limine (bootloader), Flanterm (emulação de terminal), smoltcp (pilha TCP/IP), fatfs (FAT32) e rustls (TLS). O resto — escalonador, memória virtual, compositor, syscalls, shell, toolkits de UI — é código do repositório.

O alvo é máquina modesta: um núcleo, framebuffer linear rasterizado por software, sem GPU 3D.

O que já roda

Kernel e processos

  • 27 syscalls, de SYS_EXIT (1) a SYS_CLIPBOARD (27), expostas ao Ring 3 por libcoeleo
  • Escalonador preemptivo round-robin disparado pelo timer do LAPIC, com context switch em assembly isolado em um único arquivo
  • Até 8 processos simultâneos, um thread por processo, com PCB e reaping de zumbis
  • PMM com bitmap de frames, VMM de 4 níveis, separação kernel/user e pilha de usuário de 64 KiB

Ainda estou trabalhando em melhorias para multitarefa...

Armazenamento

  • FAT32 próprio e persistente: alocação de clusters, nomes longos, truncate e sync
  • Backends VirtIO-blk, SATA AHCI com tabela GPT e USB Mass Storage, até 8 discos
  • Instalador que grava GPT + FAT32 em um disco de destino

Rede

  • smoltcp sobre virtio-net ou Intel e1000e — uma PHY por vez, escolhida na inicialização
  • DHCP com fallback estático, ARP, ping (ICMP echo), DNS tipo A e cliente HTTP com teto de 32 KiB por resposta
  • HTTPS com TLS 1.2/1.3 via rustls (provider rustls-rustcrypto, entropia por RDRAND, relógio pelo RTC). O test-phase22 sobe um servidor local e verifica os dois lados: certificado que encadeia na CA embutida passa, certificado fora dela é recusado

Interface

  • Compositor 2D em CPU sobre framebuffer linear, com clipping por dirty-rect
  • Chrome de janela — sombra, decoração, borda hairline — desenhado por SDF em coeleo-draw; o cliente Ring 3 pinta um buffer opaco
  • Até 8 superfícies simultâneas, criadas por SYS_WIN_CREATE e limitadas a 256×256 px
  • KRunner (Alt+Espaço), gerenciador de arquivos de dois painéis, notificações, e clipboard global de 4 KiB por SYS_CLIPBOARD
  • Wallpapers JPEG/PNG decodificados por crate própria, até 1.5 MiB e 2048 px de lado

Shell

  • Edição de linha estilo Readline: Ctrl+A/E/K/U/W/T/L, Alt+B/F, histórico de 128 entradas com busca reversa em Ctrl+R
  • Autocompletar por prefixo comum mais longo, aliases, source, pipes, redirecionamento e $?
  • Erros com prefixos semânticos (erro:, aviso:, dica:, uso:) e sugestão por distância de Levenshtein

Pacotes

  • .coe assinado com Ed25519 e verificado por SHA-256, com pkg install dentro do SO e o packer tools/coe-pack no host

O que ainda não tem

Uma lista do que existe, para quem for mexer saber onde o chão é firme.

  • Sem SMP. Só o BSP é inicializado; não existe bring-up dos outros núcleos. O escalonador roda em um core e a concorrência sai toda da preempção por timer. Nada escala com núcleos.
  • Um thread por processo, teto de 8 processos. Não há threads de usuário. Um app que bloqueia em syscall bloqueia inteiro, e MAX_PROC = 8 é o limite duro de concorrência.
  • Sem paginação sob demanda. O carregador de ELF mapeia os segmentos de forma eager, página a página, e não há swap, mmap nem copy-on-write. O custo em memória física é o tamanho do binário mais 64 KiB de pilha, reservados de uma vez. Também não existe memória compartilhada entre processos.
  • Userspace sem alocador. Não há malloc nem brk — a tabela de syscalls não tem chamada de memória. libcoeleo é allocation-free e aplicações usam buffers estáticos. Estrutura dinâmica em Ring 3 é trabalho manual.
  • Sem POSIX. A ABI é própria. Binário Linux não roda e código POSIX não recompila sem adaptação: não há sinais, não há fork/exec (o sh monta |, > e < direto no SYS_SPAWN, passando os fds a clonar) e não há sockets no sentido BSD.
  • FAT32 apenas. Sem journaling, sem permissões, sem uid/gid e sem links. O sistema é single-user e o filesystem não guarda dono de arquivo.
  • Rede só como cliente. Não há listen nem servidor TCP exposto ao userspace, DNS resolve só tipo A e não há IPv6.
  • Texto de UI em ASCII. A fonte embutida tem 95 glifos, cobrindo 0x200x7E. Códepoint acima de 255 vira ? e caractere Latin-1 vira caixa — então acento em nome de arquivo ou em texto de widget não aparece no desktop. O terminal é caminho separado, via Flanterm.
  • Sem áudio e sem USB genérico. O USB cobre HID (UHCI e xHCI) e Mass Storage. Não há classe de áudio nem driver de GPU — tudo é rasterizado na CPU.

Onde dá para ajudar

SMP, alocador em userspace, fonte com cobertura Unicode e um driver de GPU são as maiores lacunas. Se você nunca mexeu com OSDev, também tem espaço: o projeto tem testes automatizados por fase, então dá para pegar uma peça e ter retorno objetivo.

Antes de abrir PR, vale ler o AGENTS.md (contratos de código) e o docs/contrib/architecture.md (mapa de domínios). O docs/contrib/develop.md tem o resto.

Repositório: https://github.com/coeleo-dev/coeleo-os
Linkedin: https://www.linkedin.com/feed/update/urn:li:activity:7505752411970555904

Licença: MIT e Apache-2.0.

Carregando publicação patrocinada...
1

iniciativa legal, bato palma pra quem tem conhecimento nesse nivel;
mas qual o teu objetivo? criar pra ser legal ou pra ser util e usavel por outras pessoas?
nao tens vontade de contribuir no kernel linux ? tu parece ser um cara que gosta de otimizar as coisas, o gnome3 precisa disso rsrsr;
vi que o foco seria single thread mas com ~512mb ram (gta5 roda com isso no play3 incluindo memoria de video), nao achas melhor focar em um dispositivo mais restritivo pra ter um diferencial ?
obviamente estou sendo chato, mas se tu focar em um tipo de dispositivo tu poderias ateh vender pra intelbras, eu pensaria algo pra rodar com single thread, 32mb ram, hardware de IOT mesmo...

1

Muito obrigado hehehe

Cara, eu criei mais por hobby mesmo! Pretendo deixar ele utilizável para outras pessoas sim! E pretendo otimizar ainda mais! Na real, ele precisa de 50mb de ram pra rodar! Esqueci de ajustar esse detalhe na doc kkkk Atualmente ele está rodando em single thread mesmo, mas já estou trabalhando na implementação para multithread e umas melhorias bem significativas no escalonador!

Quero deixar ele num nível usável por usuários não tecnicos, mas também, como um parquinho para devs brincarem kkkkk Tentando deixar as bibliotecas e APIs do sistema estáveis pra facilitar a evolução e desenvolvimento utilizando outras linguagens além de Rust e até mesmo agentes de IA!