Entendendo o Kernel

Hoje em dia, quando falamos em "Linux" estamos normalmente nos referindo à plataforma como um todo, incluindo as diferentes distribuições e softwares. Mas, no início, o Linux era apenas o kernel desenvolvido pelo Linus Torvalds. Mesmo hoje em dia, alguns puristas ainda insistem na idéia de que o "Linux" é apenas o kernel e todos os outros componentes são softwares que rodam sobre ele. O principal argumento a favor dessa idéia é que outros sistemas Unix, como o FreeBSD e o Solaris são baseados em outros kernels (e são por isso considerados sistemas diferentes) mas, apesar disso, rodam o X, KDE, Firefox e outros softwares, assim como no caso das distribuições Linux. De qualquer forma, a idéia de usar o termo Linux para a plataforma como um todo é bem mais simples e natural, por isso adotamos essa terminologia no dia a dia.

O Kernel é a peça fundamental do sistema, responsável por prover a infra-estrutura básica necessária para que os programas funcionem, além de ser o responsável por dar suporte aos mais diferentes periféricos: placas de rede, som e o que mais você tiver espetado no micro.

Esta é justamente uma das principais diferenças entre o Windows e as distribuições Linux. No Windows, o sistema inclui um conjunto relativamente pequeno de drivers e você depende dos CDs de instalação e dos drivers disponibilizados pelos fabricantes. No Linux, quase todos os drivers disponíveis são incorporados diretamente no Kernel e já vêm pré-instalados nas distribuições. Isso faz com que os periféricos suportados sejam detectados automaticamente.

Isso faz com que a importância de usar uma distribuição atual seja muito maior, já que uma distribuição antiga ou desatualizada incluirá não apenas softwares antigos, mas também um conjunto desatualizado de drivers, que farão com que muitos comentes do PC não sejam reconhecidos.

Começando do início, se você der uma olhada dentro da pasta "/boot" de qualquer distribuição Linux, vai encontrar o executável do Kernel, no meio de um pequeno conjunto de arquivos. Ele é o primeiro componente carregado pelo gerenciador de boot durante a inicialização do sistema

Você deve estar se perguntando por que o arquivo se chama "vmlinuz" e não "vmlinux", como seria mais lógico. Na verdade, esta é uma longa história, mas, em resumo, o "z" no nome é usado porque o arquivo do Kernel é guardado no HD na forma de um arquivo compactado.

Nas primeiras distribuições Linux, todos os drivers e outros componentes eram compilados diretamente nesse arquivo principal e você podia escolher os componentes a ativar na hora de compilar o Kernel. Se você habilitasse tudo, não teria problemas com nenhum dispositivo suportado, tudo iria funcionar facilmente. Mas, por outro lado, você teria um Kernel gigantesco, que rodaria muito devagar no seu 486 com 8 MB de RAM. Se, por outro lado, você compilasse um Kernel enxuto e esquecesse de habilitar o suporte a algum recurso necessário, teria que recompilar tudo de novo para ativá-lo. Como resultado disso, as distribuições passaram a incluir diversas opções de kernel, compiladas com opções diferentes. Você tinha então que escolher qual usar, de acordo com os componentes do micro.

Este problema foi resolvido durante o desenvolvimento do Kernel 2.0, através do suporte a módulos. Os módulos são peças independentes que podem ser ativadas ou desativadas com o sistema em uso. Do Kernel 2.2 (lançado em 1999) em diante, quase tudo pode ser compilado como módulo, o que tornou as coisas muito mais práticas e abriu as portas para os sistemas de detecção automática de hardware que são usados nas distribuições atuais.

Os módulos nada mais são do que arquivos, que são armazenados dentro da pasta "/lib/modules/versão_do_kernel". Veja que os módulos ficam organizados em pastas: a pasta "kernel/drivers/net/" contém drivers para placas de rede, a pasta "kernel/drivers/usb/" agrupa os que dão suporte dispositivos USB e assim por diante.

Na maioria dos casos, os módulos possuem nomes que dão uma idéia do dispositivo a que oferecem suporte. O "8139too.ko" dá suporte às placas de rede com o chipset Realtek 8139, o "sis900.ko" dá suporte às placas SiS 900, enquanto o "e100.ko" ativa as placas Intel E100, por exemplo. Se você fizer uma pesquisa pelo nome de um módulo específico no Google, vai quase sempre chegar à página do projeto ou a alguma página ou manual explicando o que ele faz.

Para ativar suporte a um certo dispositivo, você (ou o utilitário de detecção incluído no sistema) precisa apenas carregar o módulo referente a ele. O resto é feito pelo próprio Kernel, que se encarrega de ativar o dispositivo e criar um caminho de acesso para ele.

Cada vez mais, o trabalho de detecção e carregamentos dos módulos está passando a ser feito de forma automática pelas distribuições, através dos códigos de identificação incluídos nos próprios dispositivos. Uma placa de rede com chipset Realtek, por exemplo, retorna algo como "Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+". Com base nesses códigos, o sistema pode descobrir quais periféricos estão instalados e carregar os módulos apropriados, de forma automática. Você pode checar os códigos de identificação dos dispositivos instalados usando os comandos "lspci" e "lsusb".

Em casos em que você precisa carregar um módulo manualmente, é usado o comando "modprobe", seguido do módulo desejado, como em:

# modprobe ndiswrapper

Para descarregar um módulo, é usado o "modprobe -r", como em:

# modprobe -r ndiswrapper

Algumas distribuições oferecem uma opção de carregar módulos adicionais durante a instalação, justamente pensando nos raros casos onde você precisa de um determinado módulo para ativar a placa SCSI onde está instalado o HD para poder prosseguir com a instalação, por exemplo.

Os módulos são gerados durante a compilação do Kernel. Você não precisa se preocupar com isso se não quiser, pois as distribuições quase sempre incluem versões bem completas do kernel por padrão, mas, de qualquer forma, existe sempre a possibilidade de recompilar o kernel, mexendo nas opções e ativando ou desativando os módulos que quiser.

Na prática, a situação mais comum onde você precisa lidar com módulos é quando precisa instalar manualmente algum driver modificado ou proprietário, necessário para ativar algum dispositivo em particular. Infelizmente, isso é ainda relativamente comum ao usar componentes recém-lançados, ou em algumas configurações problemáticas, como em alguns notebooks com chipset SiS ou VIA (nada contras os fabricantes, mas tem hora que eles fazer merd...........).