Como o sistema operacional é construído por dentro — e como ele conversa com os programas que rodam nele.
Máquina estendida (esconde o hardware) + gerenciador de recursos (organiza a fila entre processos).
CPU, memória, disco — e como o Linux expõe tudo isso em arquivos que você pode ler com cat.
Hoje: o SO não é uma caixa-preta única — existem jeitos diferentes de organizar essa caixa por dentro, e um protocolo fixo pra qualquer programa pedir ajuda a ela.
Depende do sistema operacional. Existem pelo menos 4 respostas diferentes pra essa pergunta — e vocês vão descobrir cada uma em grupo.
Tudo — processos, memória, arquivos, drivers — roda dentro de um único bloco de código, no mesmo espaço de endereçamento e com privilégios máximos.
Rápido: um módulo chama o outro direto, sem burocracia de mensagens entre processos separados.
Frágil: um driver de dispositivo com defeito roda com privilégio total e pode derrubar o sistema inteiro.
Exemplos: Linux e Windows são, na essência, monolíticos — mesmo sendo os SOs mais usados do planeta.
O mesmo trabalho do monolítico, mas organizado em níveis empilhados: cada camada só enxerga e usa a camada logo abaixo dela.
Mais fácil de entender e depurar: cada camada tem uma responsabilidade clara e uma "fronteira" definida.
Definir onde cada função entra é difícil, e forçar tudo a passar camada por camada custa desempenho.
Pioneiro: o sistema THE de Dijkstra (1968) — a ideia inspirou como pensamos em SOs até hoje, mesmo quando o código real não é tão limpo assim.
Só o essencial fica dentro do núcleo (com privilégio total). Tudo o resto — driver de disco, sistema de arquivos, driver de rede — vira processo comum, rodando no espaço do usuário.
Muito mais confiável: se o driver de áudio travar, ele derruba só o áudio — não o sistema inteiro.
Mais lento (processos precisam trocar mensagens entre si) e mais difícil de manter no dia a dia.
Onde importa de verdade: sistemas de missão crítica — controle industrial, aviônica, o QNX que roda em caças e usinas.
Em vez de dividir o núcleo, um programa especial (o monitor/hipervisor) finge, pra cada sistema operacional "convidado", que ele tem um hardware inteiro só pra si.
Isolamento forte entre sistemas — cada VM tem seu próprio núcleo completo, sem enxergar as outras.
Pesado: cada VM carrega um SO inteiro (o seu, e o de todo mundo do lado). Gasta RAM, disco e tempo de boot.
Exemplos: VirtualBox (o que vocês já usam desde a Semana 0) e VMware. Guardem esse "pesado" — ele volta em 3 slides.
Cada grupo apresenta seu card em 1 minuto. Preencham juntos o que falta na tabela.
| Arquitetura | Onde vive o código | Se um driver quebrar… | Exemplo |
|---|---|---|---|
| Monolítico | Tudo no núcleo | Sistema inteiro pode cair | Linux, Windows |
| Em camadas | Núcleo organizado em níveis | Depende da camada, mas ainda é núcleo | THE (histórico) |
| Micronúcleo | Só o essencial no núcleo | Só aquele serviço cai | QNX, MINIX 3 |
| Máquina virtual | Um núcleo inteiro por convidado | Só aquela VM é afetada | VirtualBox, VMware |
Percebam o padrão: menos coisa dentro do núcleo = mais seguro, mas geralmente mais lento. Não existe arquitetura perfeita — existe a escolha certa pro problema.
Pegadinha: um container não é uma 5ª arquitetura. Ele não tem núcleo próprio — todos os containers de uma máquina compartilham o mesmo núcleo Linux (normalmente monolítico) por baixo.
VirtualBox roda um Linux inteiro (kernel, drivers, tudo) dentro de outro Linux. Pesado, mas isolado por completo.
Docker usa namespaces e cgroups do próprio núcleo Linux pra fazer um processo achar que está sozinho na máquina — sem carregar um SO novo.
É por isso que um container sobe em milissegundos e uma VM leva segundos ou minutos: o container não faz boot de núcleo nenhum — o núcleo já está rodando, ele só empresta um pedaço isolado dele.
Não importa a arquitetura escolhida: todo SO precisa de um jeito controlado de deixar um programa comum acessar recursos protegidos (disco, rede, outros processos). Esse jeito se chama chamada de sistema (system call).
Pense na chamada de sistema como uma campainha: seu programa toca a campainha (a syscall), o núcleo atende, faz o trabalho perigoso por você, e devolve a resposta.
Toda vez que um programa abre um arquivo, lê teclado ou cria outro processo, ele está, por baixo dos panos, chamando uma dessas.
| Chamada | O que faz | Grupo |
|---|---|---|
fork | Cria um processo novo, cópia do atual | processos |
exec | Substitui o programa do processo atual por outro | processos |
wait | Espera um processo filho terminar | processos |
open | Abre um arquivo e devolve um descritor pra usá-lo | arquivos |
read | Lê bytes de um arquivo ou dispositivo já aberto | arquivos |
write | Escreve bytes em um arquivo ou dispositivo já aberto | arquivos |
close | Libera o descritor de um arquivo aberto | arquivos |
O conjunto de chamadas que um núcleo oferece define sua API. No Linux/Unix, esse padrão se chama POSIX. No Windows, é o Win32.
Existe um comando que "escuta" toda vez que um programa toca a campainha do núcleo, e imprime cada chamada na tela: strace.
Cada linha acima é uma chamada de sistema de verdade, na ordem em que o programa ls as executou. Vocês vão rodar isso — com programas diferentes — na prática de hoje.
Rodar strace em comandos simples, identificar syscalls conhecidas, comparar programas diferentes.
Comparar na prática o tempo de subida e o consumo de um container Docker contra a VM que vocês já usam.
O roteiro de laboratório detalha os dois passo a passo, com dicas se algo travar. Todas as observações vão pro instrumento semanal (quiz) no fim.
Monolítico, micronúcleo e máquina virtual, com os mesmos diagramas que vimos hoje. p. 12–13
Modo usuário x privilegiado e o conceito de API, explicado de forma direta. p. 16–17
As chamadas com nome de verdade (fork, exec, open, read...) — a base do que vocês vão ver no strace. p. 37–40
O quiz da semana verifica essa leitura e recolhe suas observações da prática — tudo no mesmo instrumento.