U9 · Gerência de dispositivos e virtualização

A CPU executa bilhões de operações por segundo; um disco responde em milissegundos, um teclado em centenas de milissegundos entre teclas. Além disso, cada dispositivo fala um "dialeto" próprio de registradores e comandos. Se cada aplicação tivesse de conhecer cada controladora, programar seria um inferno.

O subsistema de E/S do SO esconde essa diversidade e essa lentidão. Ele oferece uma interface uniforme (open/read/write) e cuida de esperar o hardware sem desperdiçar a CPU. Como ele faz isso — polling, interrupção ou DMA — é o coração desta aula.

Subimos da controladora física até a abstração de arquivo, passando pelas três formas de mover dados e pela peça que conhece cada dispositivo: o driver.

A CPU acessa os registradores da controladora de dois modos. No I/O mapeado em memória (MMIO), os registradores aparecem como endereços de memória comuns — ler/escrever neles controla o dispositivo. No I/O por portas (x86), instruções especiais (in/out) acessam um espaço de endereçamento separado.

Em ambos, o diálogo é: a CPU escreve um comando no registrador de comando, consulta o registrador de status para saber quando terminou, e troca dados pelo registrador de dados. A pergunta central é: como a CPU descobre que o dispositivo terminou? É aí que entram polling, interrupção e DMA.

O polling parece simples — um laço que lê o status até o dispositivo ficar pronto. O problema é a espera ocupada (busy-wait): a CPU queima ciclos sem fazer nada útil enquanto espera. Para um disco lento, isso desperdiça milhões de ciclos por operação.

A interrupção resolve: o dispositivo avisa quando termina, liberando a CPU para outros processos no meio-tempo. Porém, cada interrupção tem custo (salvar contexto, executar a ISR, restaurar). Em rajadas de eventos muito frequentes — uma placa de rede de 10 Gb/s, por exemplo —, o excesso de interrupções (interrupt storm) pode sufocar a CPU; daí técnicas como coalescência de interrupções e polling adaptativo.

Entre a aplicação e o dispositivo, o SO interpõe áreas de memória que melhoram desempenho e desacoplamento:

• Buffering: acumula dados para casar velocidades diferentes (a aplicação produz rápido, o disco grava devagar) e para transferir em blocos maiores e eficientes.
• Caching: mantém na RAM blocos de disco recentes (cache de páginas), evitando reler do dispositivo.
• Spooling: enfileira trabalhos para um dispositivo que não pode ser compartilhado simultaneamente, como a impressora.

Por isso, agrupar E/S em poucas operações grandes (com buffers) é muito mais eficiente que muitas operações pequenas, cada uma com seu custo de syscall e de troca de modo.

Parece contraintuitivo: interrupção não é sempre melhor que polling? Em sistemas de tempo real, nem sempre. Uma interrupção introduz latência de entrada (tempo até a CPU atender) e, pior, jitter (variação dessa latência), pois pode chegar enquanto outra ISR roda ou enquanto interrupções estão desabilitadas.

Para um laço de controle que lê um sensor a 1 kHz com prazo apertado, fazer polling sincronizado por um timer dá latência fixa e previsível, sem o overhead de salvar/restaurar contexto de cada interrupção. Determinismo, de novo, vencendo a eficiência média.

A E/S costura várias aulas:

• As interrupções retomam o tema da Aula 2 (vetor, ISR) e sustentam a preempção (Aula 5).
• O DMA e o buffering apoiam o swap (Aula 9) e o sistema de arquivos (Aula 11).
• A latência de interrupção é métrica central do tempo real (Aula 12).
• Drivers em modo núcleo ligam-se ao isolamento e segurança (Aula 13).

Virtualizar com segurança exige apoio do hardware. Quando uma VM executa uma instrução privilegiada (acessar um dispositivo, alterar a tabela de páginas), ela não pode mexer no hardware real diretamente. O hardware de virtualização (Intel VT-x, AMD-V) faz a CPU "sair" para o hipervisor (VM exit), que emula a operação e devolve o controle.

Para a memória, há tabelas de páginas aninhadas (EPT/NPT): a MMU traduz duas vezes — endereço da VM → endereço "físico" da VM → endereço físico real —, isolando a memória de cada VM. É a MMU da Aula 8 elevada a outro nível. Contêineres, por não virtualizarem hardware, dispensam isso, mas por isso isolam menos.

O coração do tempo real é o determinismo: a garantia de que toda operação termina dentro de um limite de tempo conhecido. Para provar que um sistema cumpre seus prazos, o engenheiro precisa do WCET (Worst-Case Execution Time) de cada tarefa — quanto ela leva no pior cenário possível.

O problema é que muitos recursos que melhoram a média pioram o pior caso e tornam o WCET difícil de calcular: caches (acerto ou erro?), pipelines com predição de desvio, paginação para disco, coleta de lixo. Por isso, em tempo real rígido, esses recursos são desabilitados, controlados ou substituídos por alternativas previsíveis (memória fixa, sem swap, sem GC).

O FreeRTOS é um kernel de tempo real minúsculo (poucos KB) muito usado em microcontroladores como ARM Cortex-M e ESP32. Oferece tarefas, escalonamento preemptivo por prioridade, filas, semáforos e mutex com herança de prioridade — tudo o que um sistema embarcado de tempo real precisa, sem MMU nem swap.

Em um robô ou drone, tarefas como ler IMU (alta frequência), estabilizar (controle) e telemetria (baixa frequência) coexistem com prioridades RM, comunicando-se por filas.