Entendendo o HAL
Publicado em 01/02/2009 – 20:31por Carlos Morimoto
No post de sexta-feira, comentei brevemente sobre as funções de montagem automática das partições em dispositivos removíveis, que permitem que pendrives, cartões de memória, câmeras e outros dispositivos sejam acessados de maneira muito simples e sem que você precise fornecer a senha de root.
Em distribuições antigas, o trabalho era feito através de shell-scripts, que monitoravam as mensagens do Kernel e executavam as ações apropriadas. A partir do Kernel 2.6, este trabalho ficou bem mais simples, já que, graças ao sysfs, sempre que um novo dispositivo é plugado, é adicionada uma entrada dentro da pasta "/sys".
No caso de um pendrive, por exemplo, é criada a pasta "/sys/block/sdb" (ou sdc, sdd, etc.) e, dentro dela, uma sub-pasta para cada partição dentro do pendrive, como "/sys/block/sda/sdb1". A pasta é criada quanto o pendrive é detectado, e removida quando ele é desconectado do sistema. Graças a isso, um script de detecção precisa apenas monitorar o conteúdo da pasta /sys, sem se preocupar em detectar quando o pendrive é conectado ou desconectado, pois o próprio Kernel (com a ajuda do hotplug ou UDEV) se encarrega disso.
Um script de detecção, poderia então usar uma regra para o udev como:
BUS="usb", ACTION=="add", KERNEL=="sd??", NAME="%k", RUN+="/usr/local/bin/detectar
… para ser executado sempre que um novo dispositivo fosse encontrado e uma função como:
detecta(){
cd /sys/block/
for i in `ls | grep sd`; do
cd $i; ls | grep $i; cd /sys/block/
done
}
Para verificar quais são as partições disponíveis. Você pode ver um exemplo simplificado de detecção de pendrives usando o UDEV no:
http://www.gdhpress.com.br/ferramentas/leia/index.php?p=cap4-14
Estes scripts em shell fazem o trabalho, mas eles não são exatamente uma solução muito elegante para o problema. Entra em cena então o HAL (Hardware Abstraction Layer), um serviço de sistema que se encarrega de fazer o "trabalho sujo", monitorando as mensagens do kernel e transmitindo as informações para os aplicativos.
Ele é representado pelo serviço "hald" (que fica ativo por padrão na maior parte das distribuições atuais) e trabalha em conjunto com o serviço "dbus", que controla a comunicação entre ele e os aplicativos.
Caso esteja curioso, as informações coletadas por ele podem ser exibidas usando o comando "lshal", que exibe a longa lista de informações que é monitorada pelos aplicativos.
Se você rodar o comando "ps aux | grep hald" em uma distribuição atual, vai perceber que existem várias ramificações do hald, responsáveis por monitorar diferentes dispositivos da máquina. O "pooling /dev/sdb (every 2 sec)" no screenshot, por exemplo, indica que ele está monitorando o dispositivo da câmera, realizando checagens a cada dois segundos:
O HAL é integrado a componentes do Gnome do KDE, que se encarregam de mostrar mensagens quando novos dispositivos são plugados e executar outras funções. Ao plugar uma câmera digital, por exemplo, a presença de arquivos de imagem faz com que o utilitário ofereça a opção de abrí-las diretamente com um gerenciador de fotos, em vez de simplesmente mostrar os arquivos:
No caso dos cartões de memória e partições de dados, as partições são montadas automaticamente em pastas dentro do diretório "/media" e (na maioria das distribuições), é criado um ícone no desktop, acompanhado pela abertura de uma janela do gerenciador de arquivos:
As partições são montadas de forma automática conforme você clica sobre os ícones, sem que você precise fornecer a senha de root. O HAL se encarrega de ajustar as permissões de acesso de maneira que os arquivos fiquem disponíveis apenas para o seu login (os parâmetros são detalhados no arquivo "/media/.hal-mtab").
Este sistema permite também manter a segurança em servidores de terminais e outros sistemas usados por diversos usuários simultaneamente. Você vai notar também que as entradas referentes às partições de dispositivos removíveis não são mais inseridas no fstab, uma vez que a montagem e a desmontagem é feita diretamente pelo HAL.
Além de ser responsável pelo acesso a dados em dispositivos removíveis, o HAL é utilizado em diversas outras funções do sistema. É ele o responsável por detectar quando um cabo de rede é plugado e transmitir a informação ao NetworkManager, para que ele possa ativar a rede automaticamente, ou por fornecer as informações sobre o hardware da máquina para que o gerenciador de drivers restritos do Ubuntu possa instalar os módulos necessário, por exemplo.
9 respostas para “Entendendo o HAL”
Muito interessante!
Ver os bastidores é sempre extraordinário!
Sucesso
Essa foi uma mudança muito importante. Outra que está sendo é a progressiva "morte" do xorg.conf. O xrandr faz o trabalho de lidar com monitores/resoluções/etc "a quente". evdev idem com dispositivos de entrada.
Apesar de muitos Pitecantropos acharem tudo isso muito ruim (qual é a graça de alternar entre monitores sem precisar reiniciar o X, hein?), é o inevitável caminho da evolução.
@Marcos, eu já dei muito ataque de pelanca por isso, mas o motivo, a época, era simples, quando este processo não dava certo (como no meu caso, que simplesmente não funcionava) tinha de fazer tudo manualmente, só que, a cada vez que o sistema tinha uma atualização, por minima que fosse, este sistema ia lá e retirava todas as minhas alterações no xorg.conf e mais uma vez eu ficava sem vídeo e tinha de partir para a tela preta arrumar.
Evolução certamente bem vinda, funcionalidade sem perder flexibilidade, Morimoto , já que tem tocado nesses componentes mais novos , caso haja oportunidade, poderia falar um pouco sobre o ext4 ? benefícios e perdas…
Excelente artigo, nunca achei nenhuma documentação tão direta e simplificada quanto o exposto. Sugestão: Poderia fazer um "entendendo o DBus", ou "Configurando o Hal", seriam bem interessantes!
E parabéns pelo blog, cada vez melhor.
A impressão que tenho é de que estão havendo conflitos entre a forma antiga e a nova forma de monitoramento dos dispositivos.
Meu exemplo: uso o Debian Lenny com KDE, e estava apanhando para utilizar o Network Manager no gerenciamento de minhas conexões de rede. A solução foi comentar todas as linhas relativas aos dispositivos no "/etc/networks/interfaces", com exceção das relativas à interface de loopback.
Sem isso, o Network Manager não monitorava a rede cabeada, além disso, sempre se perdiam muitos segundos durante o boot, quando o sistema tentava subir as interfaces e obter IP para ela.
Emanuel, não é bem um conflito, mas a maneira como o NetworkManager trabalha. Ele só gerencia interfaces que não estão já configuradas pelo /etc/networks/interfaces. Isso é um comportamento esperado e documentado.
Como sou um pouco mais concervador e utilizo slackware, para mim é HAL veio a pouco tempo.
Devo confessar que gostei bastente, porem tenho um duvida.
Notei que o ponto se dá em /media/$label (rotulo do pendrive, cam, celular).
Eu gostaria de montar sempre no mesmo lugar, independente do dispositivo plugado, independente do rotulo da partição.
Comecei a pesquisar hoje e ainda não achei onde posso alterar essa informação.
Se alguem tiver uma dica eu agradeço, obrigado
Eduardo, realmente é um comportamento desejável, mas sobre ser documentado…
Eu só achei a solução para o problema em um post escondido em um tópico escondido em um forum de lingua inglesa escondido lá pela 4ª página de resultados do google. Li muita coisa sobre o Network Manager e o Hal sem ver nenhuma menção sobre esse comportamento.