Sistemas operacionais baseados no kernel Linux apoiam-se fortemente em um chip chamado MMU (Memory Management Unit). Este componente de hardware fica entre a CPU e a memória, e permite virtualizar o acesso à memória do sistema.

A MMU possui uma tabela de mapeamento de memória, também chamada de page table, que contém o mapeamento dos endereços de memória virtual e físico do sistema. Todo endereçamento de memória (instrução e dados) é virtual e passa pela MMU, que irá converter para um endereço físico e realizar o acesso à memória do sistema.

Mas quais são as vantagens deste mecanismo de memória virtual? São muitas! Veremos neste artigo que este recurso facilita bastante o trabalho do sistema operacional, e que sem ele a vida fica um pouco mais complicada, tanto para o kernel quanto para o desenvolvedor de aplicações.

AS VANTAGENS DA MMU

Com a ajuda da MMU fica fácil adicionar ou remover memória à um processo em tempo de execução. É por isso que, ao desenvolver uma aplicação em um sistema com MMU, não precisamos nos preocupar com o uso do stack e do heap, que podem crescer conforme a necessidade da aplicação.

Caso o kernel precise alocar memória para um processo, mas a quantidade de memória física está limitada, ele é capaz de salvar páginas de memória física não utilizadas em disco, e remapear a região de memória para outro processo. Este é o mecanismo que conhecemos como SWAP ou paginação de memória, que permite expandir a quantidade de memória do sistema utilizando uma ou mais partições do disco, em troca de uma perda de performance.

A MMU possibilita também proteção no acesso à memória. Caso um processo tente acessar uma região de memória que ele não tenha permissão de acesso, o kernel irá enviar ao processo o sinal SIGSEGV, encerrando sua execução com a mensagem de erro “Segmentation Fault“.

Outra vantagem da MMU é o compartilhamento de memória entre processos. Por exemplo, se diversos processos compartilharem o uso de uma mesma biblioteca, a seção de código da biblioteca será carregada para a memória apenas uma vez, e será compartilhada por todas as aplicações.

Mas e o Linux sem MMU, funciona?

SEM MMU

Sim, funciona. Mas com várias limitações.

Sem memória virtual, o processo precisa ficar em uma região fixa (e normalmente contínua) de memória. A região de memória do processo não pode ser expandida facilmente, porque as regiões de memória próximas ao processo podem estar sendo utilizadas por outro processo.

Neste caso, o processo deve ser capaz de ser executado em qualquer posição de memória. Para isso, ele deve conseguir corrigir seus endereços antes da execução (seu código deve ser relocável), ou então ele deve ser compilado de forma que todo o endereçamento seja relativo (PIC – Position Independent Code). Por este motivo, o formato ELF de executável não é suportado, e sim um formato específico chamado flat format.

Um sistema sem MMU não possui a chamada de sistema fork(), já que não é possível facilmente duplicar as regiões de código e o stack do processo pai para o processo filho. Para estes casos, deve-se usar a chamada de sistema vfork(), onde o processo pai bloqueia enquanto o processo filho não retornar. E o processo filho possui diversas limitações, como por exemplo, ele não deve utilizar o stack do processo pai. Costuma ser trabalhoso portar aplicações que usam o fork() para o vfork().

Sem memória virtual não é possível ter um stack dinâmico, então o desenvolvedor precisa se preocupar com a alocação do stack no desenvolvimento e definir um valor para o stack em tempo de compilação. E como também não é possível alocar memória dinamicamente (a função sbrk() não existe), a função malloc() é reimplementada utilizando a chamada de sistema mmap(), onde a memória utilizada vem de um pool de memória global do kernel. A fragmentação de memória costuma ser um problema, pelo fato de não ser simples agrupar regiões não-continuas de memória.

Sem MMU significa também que não existe proteção no acesso à memória, e costuma ser extremamente complicado e trabalhoso rastrear e identificar este tipo de problema.

As bibliotecas compartilhadas precisam ser compiladas com XIP (Execution-In-Place) para que possam ser linkadas e compartilhadas pelas aplicações. Caso contrário, cada aplicação terá que utilizar sua versão de biblioteca, o que irá causar grande desperdício de memória RAM, além de possíveis problemas com licença.

Também não é possível fazer SWAP sem MMU, e alguns recursos do kernel que dependem de memória virtual podem não funcionar, como o sistema de arquivos virtual tmpfs.

Apesar de todas estas deficiências, pode-se considerar o uso do Linux em plataformas mais modestas, sem MMU, e que requerem recursos do Linux como a implementação da pilha de protocolos TCP/IP, sistemas de arquivos, camada gráfica e o ecossistema de aplicações e ferramentas disponíveis. É aí que entra o uClinux.

UCLINUX

O uClinux (lê-se you-see-Linux) é um projeto criado em 1998 como um fork do kernel Linux para microcontroladores e processadores de 32 bits sem uma unidade de gerenciamento de memória (MMU), e que hoje é basicamente uma distribuição Linux completa com toolchain, kernel e um conjunto de bibliotecas e aplicações.

Criado inicialmente para suportar o modelo Dragonball da família de processadores 68K da Motorola, hoje ele suporta diversas outras arquiteturas como Coldfire, Blackfin, ARM, Nios (Altera), Microblaze (Xilinx), MIPS e ARM, e é utilizado em diversos dispositivos embarcados como roteadores, cameras, MP3 players, telefones VoIP e leitores de DVD.

Ele possui uma interface de configuração baseada na ferramenta kbuild do kernel, e permite selecionar o target e os pacotes para a distribuição que será gerada.

DEVO USAR?

Evite, se possível.

São tantas as limitações e riscos de utilizar um sistema Linux sem MMU, que a economia no custo no hardware pode não compensar e esforço e investimento de tempo no software para colocar tudo para funcionar. E conforme os SoCs evoluem e ficam mais baratos, soluções com o uClinux ficarão cada vez mais obsoletas. De qualquer forma, é sempre bom conhecer todas as alternativas.

Um abraço!

Sergio Prado