O que você vai aprender
Diferenciar modo usuário e modo núcleo.
Explicar o papel das chamadas de sistema e das interrupções.
Comparar arquiteturas monolítica, em camadas e microkernel.
Descrever o caminho de uma operação do programa até o kernel.
Por que olhar para dentro do SO?
Na aula anterior vimos o que o SO faz. Agora abrimos a "caixa-preta": como ele é organizado internamente para fazer tudo isso com segurança e desempenho.
A pergunta central é: como permitir que aplicações peçam serviços poderosos (acessar disco, criar processos) sem deixá-las executar diretamente instruções perigosas que poderiam travar ou corromper a máquina? A resposta envolve modos de execução, chamadas de sistema e uma boa arquitetura.
O que veremos nesta aula
e modos→Chamadas
de sistema→Interrupções
e traps→Arquiteturas
Kernel e os dois modos
Modo usuário. Estado restrito em que aplicações rodam, sem acesso direto ao hardware.
Um bit de status no processador indica o modo atual. Instruções privilegiadas (acessar dispositivos, mudar tabelas de memória) só executam em modo núcleo.
Por que separar os modos
A separação de modos é uma proteção de hardware. Se uma aplicação tentar executar uma instrução privilegiada em modo usuário, o processador gera uma exceção e o SO assume o controle.
Assim, um programa com bug ou malicioso não consegue, por exemplo, apagar a memória de outro processo ou desligar o disco diretamente — ele precisa pedir, e o SO decide.
Tabela: modo usuário × modo núcleo
| Modo usuário | Modo núcleo | |
|---|---|---|
| Privilégios | Restritos | Totais |
| Acesso a hardware | Indireto (via SO) | Direto |
| Instruções privilegiadas | Proibidas | Permitidas |
| O que roda | Aplicações | Kernel do SO |
Stepper: uma chamada de sistema
Chamada de sistema (system call)
É a única porta legítima de entrada no kernel. Bibliotecas (como a libc) embrulham as chamadas em funções convenientes, mas, no fundo, há sempre um trap.
Categorias de chamadas de sistema
As chamadas de sistema costumam ser agrupadas por finalidade:
- Controle de processos: fork, exec, exit, wait.
- Arquivos: open, read, write, close.
- Dispositivos: ioctl, read/write em dispositivos.
- Informação: getpid, time.
- Comunicação: pipe, socket, send, receive.
Código: read() é uma chamada de sistema
Interrupções e traps
Trap (exceção). Desvio causado pela própria execução do programa (chamada de sistema, divisão por zero). É síncrono.
Ambos transferem o controle para o kernel de forma protegida, executando uma rotina de tratamento.
O fluxo de uma chamada de sistema
modo usuário→Trap /
chamada→Kernel
modo núcleo→Retorno
modo usuário
Note que há duas trocas de modo: usuário→núcleo na entrada e núcleo→usuário na volta.
Arquiteturas de kernel
| Arquitetura | Ideia | Trade-off |
|---|---|---|
| Monolítica | Todo o SO em um único kernel | Rápida, porém difícil de manter (ex.: Linux) |
| Em camadas | Níveis sobrepostos, cada um usa o de baixo | Organizada, mas pode ter overhead |
| Microkernel | Kernel mínimo; serviços em modo usuário | Robusta e modular, com mais troca de mensagens (ex.: MINIX) |
| Híbrida | Mistura monolítico com ideias de microkernel | Equilíbrio (ex.: Windows NT, macOS) |
Verifique: onde roda o kernel
Em que modo o kernel do SO executa?
Microkernel e robustez
Em um microkernel, drivers e o sistema de arquivos rodam como processos em modo usuário. Se o driver de rede travar, ele pode ser reiniciado sem derrubar o kernel.
Em um kernel monolítico, esse mesmo driver roda dentro do núcleo: um bug nele pode causar uma falha geral (tela azul/kernel panic). É o preço da velocidade extra.
Onde a intuição falha
• A aplicação não "entra no kernel" executando código privilegiado próprio — ela faz um pedido via chamada de sistema.
• Interrupção (assíncrona, do hardware) não é o mesmo que trap (síncrono, do programa).
• Linux é monolítico (mesmo sendo modular); microkernel é a ideia do MINIX, não do Linux.
Mnemônicos úteis
• "Usuário pede, núcleo faz."
• Trap = Tarefa do programa (síncrono). Interrupção = vem de fora (assíncrono).
• Toda chamada de sistema tem duas trocas de modo: entrada e saída.
Revele: por que não acesso direto
Por que um programa de usuário não pode acessar o disco diretamente, mesmo que isso fosse mais rápido?
Revisão relâmpago
O guichê do banco
Para onde isto leva
- Chamadas de controle de processos (fork/exec) → Aula 3.
- Interrupções reaparecem no escalonamento (timer) → Aula 5.
- Comunicação (pipe, socket) → Aula 6.
- Proteção de modos sustenta toda a segurança do curso.
Fechando a aula
Atividade em grupo · Mapeando uma chamada de sistema
Em duplas, sigam o caminho de uma operação até o kernel.
Roteiro
- Escolham uma operação: abrir arquivo, criar processo ou alocar memória.
- Desenhem o fluxo: programa → chamada de sistema → trap → kernel → retorno.
- Indiquem em que pontos ocorrem as trocas de modo usuário↔núcleo.
- Discutam por que o programa não pode acessar o hardware diretamente.
Mini-quiz · Aula 2
20 questões sobre esta aula. Escolha e veja a explicação na hora.
📌 Resumo — leve isto para a prova
- O kernel roda em modo núcleo; aplicações, em modo usuário.
- Chamadas de sistema são a interface controlada para pedir serviços ao kernel.
- A troca de modo é protegida por hardware (trap); interrupções vêm do hardware (assíncronas).
- Toda chamada de sistema tem duas trocas de modo: entrada e retorno.
- Arquiteturas: monolítica (rápida), em camadas (organizada), microkernel (modular) e híbrida (equilíbrio).