Tipos de Sistemas Operacionais

Modulo 1 · Aula 3 ~15 min de leitura Nivel: Introdutorio

Video da aula estara disponivel em breve

Arquitetura de Kernel

A decisao mais fundamental no design de um SO e: o que roda dentro do kernel (modo privilegiado) e o que roda fora (modo usuario)? Essa decisao define a arquitetura do kernel e tem consequencias profundas sobre desempenho, seguranca, e manutenibilidade.

Kernel Monolitico

No kernel monolitico, todos os servicos do SO — gerencia de processos, memoria, sistema de arquivos, drivers, rede — rodam juntos no mesmo espaco de enderecamento, em modo kernel.

Diagrama — Kernel Monolitico

User Mode
+----------+  +----------+  +----------+
|  App A   |  |  App B   |  |  App C   |
+----------+  +----------+  +----------+
============ System Call Interface ============
Kernel Mode
+------------------------------------------------+
|              Kernel Monolitico                 |
|                                                |
|  +----------+ +----------+ +----------+       |
|  | Scheduler| | Memory   | | File     |       |
|  | Manager  | | Manager  | | System   |       |
|  +----------+ +----------+ +----------+       |
|  +----------+ +----------+ +----------+       |
|  | Network  | | Device   | | IPC      |       |
|  | Stack    | | Drivers  | | Manager  |       |
|  +----------+ +----------+ +----------+       |
|                                                |
|  Tudo no MESMO espaco de enderecamento.        |
|  Uma chamada de funcao entre subsistemas.      |
+------------------------------------------------+
|                 Hardware                       |
+------------------------------------------------+

Vantagens:

Desempenho: chamadas entre subsistemas sao chamadas de funcao normais (sem overhead de IPC)
Acesso direto: qualquer parte do kernel pode acessar qualquer estrutura de dados

Desvantagens:

Um bug em um driver pode derrubar o kernel inteiro (sem isolamento)
Codebase gigantesco e dificil de manter (Linux: ~30 milhoes de linhas)
Dificil de modularizar e testar componentes individualmente

Exemplos: Linux, FreeBSD, MS-DOS. O Linux mitiga as desvantagens com loadable kernel modules (LKMs) — drivers podem ser carregados e descarregados dinamicamente, mas ainda rodam em kernel mode.

Shell

# Listar modulos carregados no kernel Linux
$ lsmod | head -10
Module                  Size  Used by
nvidia               2345678  0
snd_hda_intel          54321  3
ext4                  876543  1
ip_tables              32100  2

# Carregar um modulo dinamicamente
$ sudo modprobe vfat    # driver para FAT32

# Remover um modulo
$ sudo rmmod vfat

# Ver informacoes de um modulo
$ modinfo ext4

Microkernel

A filosofia oposta: manter no kernel apenas o minimo absoluto — escalonamento basico, IPC (Inter-Process Communication), e gerencia de memoria de baixo nivel. Todo o resto (drivers, sistema de arquivos, rede) roda como processos em modo usuario.

Diagrama — Microkernel

User Mode
+--------+ +--------+ +--------+ +--------+ +--------+
| App A  | | File   | | Device | | Network| | App B  |
|        | | Server | | Driver | | Server | |        |
+--------+ +--------+ +--------+ +--------+ +--------+
     |          |          |          |          |
     +-----+----+-----+----+-----+----+-----+---+
           |          |          |          |
     ======|=== IPC ==|==========|==========|======
           |          |          |          |
Kernel Mode (minimo)
+--------------------------------------------------+
|  +--------+  +--------+  +----------------+     |
|  |Schedule |  | Memory |  | IPC (message   |     |
|  |  -er    |  | (basic)|  |   passing)     |     |
|  +--------+  +--------+  +----------------+     |
+--------------------------------------------------+
|                  Hardware                        |
+--------------------------------------------------+

Comunicacao entre servicos: message passing via IPC
(mais lento que chamada de funcao, porem isolado)

Vantagens:

Isolamento: crash de um driver nao derruba o kernel — o servico e reiniciado
Seguranca: superficie de ataque minima no kernel
Modularidade: servicos podem ser adicionados/removidos/atualizados independentemente
Portabilidade: nucleo pequeno e mais facil de portar para novo hardware

Desvantagens:

Overhead de IPC: cada interacao entre servicos requer troca de mensagens (context switch)
Latencia: uma operacao de I/O pode exigir multiplas mensagens entre servicos

Exemplos: Mach, QNX, MINIX 3, seL4, GNU Hurd. O macOS usa um kernel hibrido baseado no Mach + BSD (XNU).

O debate Torvalds vs. Tanenbaum Em 1992, Andrew Tanenbaum (criador do MINIX) e Linus Torvalds tiveram um debate publico famoso sobre microkernel vs. monolitico. Tanenbaum argumentou que kernels monoliticos eram "um passo atras". Torvalds argumentou que performance era mais importante que pureza arquitetural. 30+ anos depois, Linux (monolitico) domina, mas microkernels prosperam em nichos como sistemas embarcados e verificacao formal (seL4).

Kernel em Camadas

Uma abordagem intermediaria: organizar o kernel em camadas hierarquicas, onde cada camada so usa servicos da camada imediatamente abaixo. O THE System (Dijkstra, 1968) foi o primeiro a usar essa abordagem.

Diagrama — Kernel em Camadas

+-------------------------------------------+
| Camada 5: Programas de Usuario            |
+-------------------------------------------+
| Camada 4: I/O e Device Drivers            |
+-------------------------------------------+
| Camada 3: Comunicacao Inter-Processo      |
+-------------------------------------------+
| Camada 2: Gerencia de Memoria             |
+-------------------------------------------+
| Camada 1: Escalonamento de CPU            |
+-------------------------------------------+
| Camada 0: Hardware                        |
+-------------------------------------------+

Regra: Camada N so pode chamar Camada N-1.
Vantagem: cada camada pode ser testada isoladamente.
Desvantagem: nem sempre e claro onde colocar cada funcao.
Desvantagem: overhead de passar por multiplas camadas.

Exokernel

Abordagem radical do MIT (1990s): o kernel nao fornece abstracoes — apenas multiplexa hardware de forma segura. Cada aplicacao implementa suas proprias abstracoes (seu proprio sistema de arquivos, seu proprio gerenciador de memoria) em bibliotecas chamadas LibOS.

Diagrama — Exokernel

+----------+  +----------+  +----------+
|  App A   |  |  App B   |  |  App C   |
| +------+ |  | +------+ |  | +------+ |
| |LibOS | |  | |LibOS | |  | |LibOS | |  cada app traz
| | (FS, | |  | | (FS, | |  | | (FS, | |  suas proprias
| | MM)  | |  | | MM)  | |  | | MM)  | |  abstracoes
| +------+ |  | +------+ |  | +------+ |
+----------+  +----------+  +----------+
========= Secure Multiplexing API =========
+------------------------------------------+
|           Exokernel                      |
|  (apenas protecao e multiplexacao)       |
|  Sem abstracoes. Sem filesystem.         |
|  Sem gerencia de memoria virtual.        |
+------------------------------------------+
|              Hardware                    |
+------------------------------------------+

A ideia e que o SO tradicional impoe abstracoes que nem toda aplicacao precisa. Um banco de dados pode querer controlar exatamente quais blocos de disco usa. Um servidor web pode querer seu proprio scheduler. O exokernel permite isso.

Relevancia moderna: unikernels (MirageOS, Unikraft) e eBPF no Linux seguem a filosofia exokernel — permitir que aplicacoes customizem comportamento do kernel.

Kernel baseado em VM (Hypervisor)

Em vez de um kernel que roda aplicacoes, um hypervisor que roda sistemas operacionais inteiros. Cada SO roda em uma maquina virtual isolada.

Diagrama — Hypervisor (Tipo 1 e Tipo 2)

Tipo 1 (Bare-metal):             Tipo 2 (Hosted):
+------+ +------+ +------+      +------+ +------+
|Guest | |Guest | |Guest |      |Guest | |Guest |
| OS 1 | | OS 2 | | OS 3 |      | OS 1 | | OS 2 |
+------+ +------+ +------+      +------+ +------+
==========================       +----------------+
|     Hypervisor         |       |   Hypervisor   |
| (Xen, VMware ESXi,    |       | (VirtualBox,   |
|  Hyper-V, KVM*)        |       |  VMware WS)    |
+------------------------+       +----------------+
|      Hardware          |       |    Host OS     |
+------------------------+       +----------------+
                                 |    Hardware    |
                                 +----------------+

* KVM e tecnicamente Tipo 1 integrado ao kernel Linux

Virtualizacao e a base de toda cloud computing moderna. AWS EC2 usa Xen/Nitro, Google Cloud usa KVM, Azure usa Hyper-V.

Comparacao Rapida

Tabela Comparativa

| Arquitetura  | No kernel          | Performance | Isolamento | Exemplo       |
|--------------|--------------------|-------------|------------|---------------|
| Monolitico   | Tudo               | Alta        | Baixo      | Linux         |
| Microkernel  | IPC + sched + MM   | Media       | Alto       | QNX, seL4     |
| Camadas      | Camadas empilhadas | Media       | Medio      | THE System    |
| Exokernel    | Multiplexacao      | Muito alta  | Alto       | MIT Exokernel |
| Hypervisor   | Multiplexacao VMs  | Media-baixa | Muito alto | Xen, KVM      |

Sistemas Hibridos na Pratica

Na pratica, quase nenhum SO moderno se encaixa perfeitamente em uma unica categoria:

Linux: monolitico com modulos dinamicos + eBPF (exokernel-like) + KVM (hypervisor) + namespaces/cgroups (container isolation)
Windows NT: microkernel hibrido — kernel mode tem mais componentes que um microkernel puro, mas menos que um monolitico
macOS (XNU): microkernel Mach + kernel monolitico BSD + IOKit (drivers em C++)

Containers: o melhor dos dois mundos? Containers (Docker) usam features do kernel Linux (namespaces, cgroups) para criar isolamento sem o overhead de uma VM completa. Nao e um novo tipo de kernel — e uma feature do kernel monolitico que oferece isolamento similar ao de um hypervisor.

No harness.os

O harness.os adota explicitamente o modelo microkernel na sua nomenclatura e arquitetura:

harness.os = kernel: o nucleo minimo — schema de banco, tools MCP basicas (start_session, log_decision, get_knowledge), e o protocolo de sessao. Nao implementa logica de negocio.
marco.os, build.os, cortex.os = distribuicoes: cada "distro" configura o kernel para um contexto diferente, com regras, workflows, e knowledge especificos. Assim como Ubuntu e Fedora usam o kernel Linux com diferentes pacotes.
MCP tools = system calls: a interface entre agentes (user mode) e o harness (kernel mode). Um agente nao acessa o banco diretamente — usa tools como start_session(), get_knowledge().
Knowledge chunks = servicos em user mode: o conhecimento nao esta hardcoded no kernel. Ele e carregado sob demanda, como um file server num microkernel.

Diagrama — harness.os como Microkernel

Agentes (User Mode)
+----------+  +----------+  +----------+
| Claude   |  | build.ai |  | cortex   |
| Session  |  | Agent    |  | Agent    |
+----------+  +----------+  +----------+
     |              |              |
===  MCP Tools (System Call Interface)  ===
     |              |              |
+--------------------------------------------------+
|  harness.os Kernel                               |
|  +----------+  +----------+  +------------+     |
|  | Session  |  | Knowledge|  | Event      |     |
|  | Lifecycle|  | Router   |  | Logger     |     |
|  +----------+  +----------+  +------------+     |
+--------------------------------------------------+
|  Neon Postgres (Hardware)                        |
+--------------------------------------------------+

As "distros" (marco.os, build.os) sao configuracoes
do mesmo kernel, nao forks. Compartilham o schema
mas diferem em rules, workflows, e knowledge loaded.

A escolha do modelo microkernel nao foi acidental. Assim como num microkernel real, a vantagem e que cada "servico" (knowledge domain, workflow, rule set) pode ser adicionado, removido, ou atualizado sem afetar o nucleo. Um bug num workflow de QA nao derruba o harness inteiro.

Homework

O harness.os usa o modelo microkernel por design. Mas e se usasse outra arquitetura?

Liste 3 coisas que teriam que estar "dentro do kernel" num harness monolitico (ou seja, hardcoded no MCP server em vez de no banco de dados).
Qual seria a vantagem de performance? (Dica: pense em quantas queries ao banco cada tool call faz.)
Qual seria a desvantagem de manutenibilidade? (Dica: o que acontece quando voce quer mudar uma regra?)
Desenhe um diagrama mostrando como seria um "harness.os exokernel" — onde cada agente traz suas proprias abstracoes (LibOS) em vez de usar as do harness.

Resumo

Kernel monolitico: tudo no kernel, rapido mas fragil (Linux)
Microkernel: minimo no kernel, isolado mas overhead de IPC (QNX, seL4)
Camadas: hierarquia rigida, bom para ensino, raro na pratica
Exokernel: sem abstracoes, aplicacoes controlam tudo (academico)
Hypervisor: roda SOs inteiros isolados (base da cloud)
Na pratica, SOs modernos sao hibridos

Verifique seu entendimento

Em um microkernel, onde roda o driver de um dispositivo de rede?

Dentro do kernel, em modo privilegiado, junto com o escalonador
Em modo usuario, como um processo separado que se comunica via IPC
Em uma maquina virtual isolada gerenciada por um hypervisor
Na LibOS da aplicacao que precisa de rede

Verifique seu entendimento

Qual a principal razao pela qual o Linux e classificado como monolitico, apesar de suportar modulos dinamicos (LKMs)?

Porque nao suporta virtualizacao
Porque os modulos sao escritos em C
Porque os modulos carregados rodam em kernel mode, no mesmo espaco de enderecamento
Porque nao permite comunicacao entre processos via IPC

Aula anterior 1.2 Historia e Evolucao dos SO Proxima aula 2.1 Conceito de Processo