Módulos

Por:

Como vimos, uma das tarefas mais importantes do Kernel é oferecer suporte ao hardware da máquina.

No começo, a questão era mais simples, pois não existiam periféricos USB, softmodems e muito menos placas Wireless. O Kernel oferecia suporte apenas ao arroz com feijão, como HD, placa de vídeo e drive de disquetes.

Como tempo foi sendo adicionado suporte a muitos outros dispositivos: placas de som, placas de rede, controladoras SCSI, etc. O fato do Kernel ser monolítico começou a atrapalhar bastante.

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 você compilasse um Kernel enxuto e esquecesse de habilitar o suporte à algum recurso necessário, teria que recompilar tudo de novo para ativá-lo.

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
em diante, quase tudo pode ser compilado como módulo.

Isso tornou as coisas muito mais práticas, pois passou ser possível compilar um Kernel com suporte a quase tudo, com todas as partes não essenciais compiladas como módulos. O Kernel em sí é um executável pequeno, que consome
pouca RAM e roda rápido, enquanto os módulos ficam guardados numa pasta do HD até que você precise deles.

Você podia carregar o módulo para a SoundBlaster 16 (do 486 que você usava na época ;-)) por exemplo, com um:

# modprobe sb

E descarregá-lo com um:

# modprobe -r sb

Esta idéia dos módulos deu tão certo que é usada até hoje e num nível cada vez mais extremo. Para você ter uma idéia, no Kernel 2.6 até mesmo o suporte a teclado pode ser desativado ou compilado como módulo, uma modificação
que parece besteira num PC, mas que é útil para quem desenvolve versões para roteadores e outros dispositivos que realmente não possuem teclado :-).

As distribuições passaram então a vir com versões do Kernel cada vez mais completas, incluindo em muitos casos um grande número de patches para adicionar suporte a ainda mais dispositivos, naturalmente quase tudo compilado
como módulo.

Nas distribuições atuais, o hardware da máquina é detectado durante a instalação e o sistema é configurado para carregar os módulos necessários durante o boot. Isto pode ser feito de duas formas:

1- Os módulos para ativar a placa de som, rede, modem e qualquer outro dispositivo “não essencial” são especificados no arquivo /etc/modules. Programas de detecção, como o
hotplug e udev, ficam de olho nas mensagens do Kernel e carregam módulos adicionais conforme novos dispositivos (uma câmera digital USB, em modo de transferência, por exemplo) são detectados.

A sua placa de som seria ativada durante o boot através de um módulo especificado no /etc/modules, assim como o suporte genérico a dispositivos USB. Mas, o seu pendrive, que você pluga e despluga toda hora é ativado
e desativado dinamicamente através da detecção feita pelo hotplug.

A detecção de novos periféricos (principalmente ao usar o Kernel 2.6) é muito simplificada graças ao próprio Kernel, que gera mensagens sempre que um novo dispositivo é encontrado. Você pode acompanhar este log rodando o
comando “dmesg“. Por exemplo, ao plugar um pendrive USB, você verá algo como:

usb 2-2: new high speed USB device using address
scsi1 : SCSI emulation for USB Mass Storage devices
Vendor: LG CNS Model: Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 249856 512-byte hdwr sectors (128 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
sda: sda1
Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 0
USB Mass Storage device found at 5

Veja que aqui estão quase todas as informações referentes a ele. O fabricante (LG), o dispositivo pelo qual ele será acessado pelo sistema (sda), a capacidade (128 MB) e até as partições existentes (neste caso uma única
partição, nomeada como sda1)

Um segundo arquivo, o /etc/modules.conf (ou /etc/conf.modules>, dependendo da distribuição usada) especifica opções e parâmetros para os módulos, quando necessário. Este arquivo
normalmente gerado automaticamente pelas ferramentas de detecção de hardware ou ao rodar o comando “update-modules“, mas pode também ser editado manualmente caso necessário.

Outra peça importante é o arquivo /lib/modules/2.x.xx/modules.dep, que guarda uma tabela com as dependências dos módulos, ou seja, de quais outros módulos cada um precisa para ser carregado corretamente.
Este último arquivo é gerado automaticamente ao rodar o comando “depmod -a“. Em geral este comando é executado automaticamente durante o boot, quando necessário.

2- Se o suporte a algo essencial nas etapas iniciais do boot não está carregado no Kernel é criado um initrd, uma imagem com os módulos necessários, que diferentemente dos módulos especificados no
/etc/modules, são carregados logo no início do boot. O initrd é guardado na pasta /boot, junto com o executável principal do Kernel: o arquivo vmlinuz.

Imagine por exemplo que você está usando uma distribuição onde o suporte ao sistema de arquivos ReiserFS foi compilado como módulo, mas quer instalar o sistema numa partição reiserfs. Isso gera um problema do tipo o ovo e a
galinha, já que o sistema precisa do módulo para acessar a partição, mas precisa de acesso à partição para poder ler o módulo.

Para evitar este tipo de problema, o próprio instalador da distribuição, ao perceber que você formatou a partição raiz em ReiserFS, vai se encarregar de gerar o arquivo initrd, que embora não seja obrigatório (é possível
compilar tudo diretamente no Kernel) é bastante usado.

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X