O kernel Linux está cada vez mais presente nos dispositivos que utilizamos no dia-a-dia, incluindo os celulares que carregamos no bolso, o roteador Wi-Fi que temos em casa, o set-top-box da TV por assinatura, as TVs inteligentes que temos na sala, o modem da Internet de banda larga, a central de entretenimento em um veículo moderno, a máquina de cartão de crédito da vendinha da esquina, e por aí vai.

Se ainda não conquistamos o desktop, o mundo dos sistemas operacionais para sistemas embarcados é algo que dominamos há um bom tempo.

Porém, ainda temos muitos desafios pela frente. E pelo menos por enquanto, existem algumas situações onde o Linux não conseguiu chegar de forma efetiva, incluindo:

1. Soluções que exigem certificação de código-fonte. Como certificar as mais de 20 milhões de linhas de código-fonte do kernel Linux?
2. Sistemas hard real-time. O kernel Linux (puro) não serve para soluções que exigem um sistema operacional hard real-time.
3. Dispositivos e periféricos com hardware (CPU, RAM e flash) bastante limitados como sensores, wearables, etc.

Mas é claro que a comunidade gosta de desafios e não desiste fácil.

O primeiro problema é o que está mais longe de ser resolvido, e ainda não existe uma solução para resolver a questão da certificação do código-fonte do kernel Linux.

Para o segundo problema, já existem soluções como os patches de tempo-real PREEMPT_RT que possibilitam o uso do Linux em sistemas soft real-time e o Xenomai que permite o uso do Linux em sistemas hard real-time.

E para o terceiro problema, existe uma iniciativa chamada The Linux Kernel Tinification, cujo objetivo é diminuir o tamanho final da imagem do kernel e reduzir ao máximo o consumo de RAM e flash.

KERNEL TINIFICATION

A cada versão do kernel centenas de milhares de linhas de código são adicionadas ao projeto. E apesar do Linux ser bastante modular, mesmo com boa parte das funcionalidades desabilitadas, o kernel acabou crescendo bastante em termos de consumo de recursos, e começou a ficar bastante difícil rodar o Linux em dispositivos limitados, com por exemplo alguns megabytes de memória RAM.

O objetivo do projeto The Linux Kernel Tinification é melhorar este cenário, de diversas formas, dentre elas:

1. Removendo chamadas de sistema não utilizadas ou mesmo tornando sua compilação opcional.
2. Removendo funcionalidades não utilizadas como sistemas de arquivos, control groups, namespaces, KVM, ferramentas de tracing como kprobes e perf, suporte a hardware como USB e GPU, etc.
3. Alterando alguns algoritmos do kernel para uma versão mais simplificada.
4. Desabilitando a compilação de mensagens de log via printk.
5. Mudando o método de compressão do kernel de GZIP para XZ para economizar espaço em flash.
6. Executando o kernel direto da memória flash (XIP – eXecution In Place) para economizar memória RAM.
7. Habilitando no compilador algumas opções de otimização de compilação por tamanho.
8. Habilitando no compilador otimização em tempo de linkagem (LTO – link time optimization), possibilitando por exemplo, durante o processo de linkagem, remover da imagem final código não utilizado pelo kernel.

É lógico que algumas destas alterações, como por exemplo remover chamadas de sistema, pode quebrar uma aplicação rodando em espaço de usuário, então é necessário conhecer detalhadamente as necessidades das aplicações que irão rodar em espaço de usuário para “tinificar” o kernel.

ALGUNS TESTES

Uma imagem do kernel com uma configuração típica para um PC (x86), tem em torno de 6MB de tamanho:

$ make ARCH=x86 i386_defconfig
$ make ARCH=x86 bzImage -j8
$ ls -l arch/x86/boot/bzImage
-rw-rw-r-- 1 sprado sprado 6126304 Fev 8 21:50 arch/x86/boot/bzImage

Seguindo os procedimentos descritos no site do projeto, a imagem final cai para impressionantes 360KB!

$ make ARCH=x86 tinyconfig
$ make ARCH=x86 bzImage -j8
$ ls -l arch/x86/boot/bzImage
-rw-rw-r-- 1 sprado sprado 360976 Fev 8 21:52 arch/x86/boot/bzImage

PRECISAMOS DISSO?

Muitos podem perguntar o porquê desta preocupação de adaptar o kernel para rodar em dispositivos limitados. Não bastaria adicionar alguns MBs de RAM e flash no hardware? Sim, esta poderia ser uma solução. Mas e se a idéia é vender centenas de milhares de dispositivos? Uma pequena alteração no hardware pode custar milhões, e qualquer economia no hardware é válida neste casos.

E porque então não utilizar um RTOS ao invés do kernel Linux? Esta é uma boa pergunta, e diversos RTOS’s como o Zephyr, o Contiki e o NuttX estão aí para nos mostrar que existem boas alternativas de código-aberto ao kernel Linux. Quem estiver interessado neste assunto pode ler um artigo que escrevi sobre Sistemas Operacionais com foco na Internet das Coisas.

Porém, comparado ao kernel Linux, estes sistemas operacionais de tempo real têm algumas desvantagens. Dentre elas, nenhum destes RTOS’s tem o suporte a hardware que tem o kernel Linux, a comunidade de usuários e desenvolvedores do kernel Linux é infinitamente maior, e apesar de muitos deles terem uma interface POSIX, nenhum deles se beneficia do que já existe em termos de aplicações e bibliotecas disponíveis para o espaço de usuário do kernel Linux.

Se o kernel Linux vai competir neste mercado de sistemas operacionais para dispositivos limitados, cuja tendência é crescer cada vez mais com esta onda de investimentos em Internet das Coisas, é algo que veremos nos próximos anos!

Um abraço,

Sergio Prado