Guia de udev do GentooQuando usuários de Linux falam sobre o hardware em seu sistema na companhia de pessoas que acreditam que o Linux é um tipo de vírus ou marca de café, o uso de "barra dev barra algo" com certeza trará um olhar estranho. Mas para os felizes usuários (e isso inclui você) usar /dev/hda1 é só um jeito rápido de explicar que estamos falando do primeiro IDE mestre, primeira partição. Ou não estamos? Nós todos sabemos o que é um arquivo de dispositivo. Alguns até sabem porque arquivos de dispositivos têm número especiais quando os vemos mais de perto rodando ls -l em /dev. Mas o que sempre tomamos como garantido é que o disco IDE mestre primário é referido como /dev/hda. Você pode não concordar, mas isso é uma falha de desenho. Pense sobre dispositivos que fazem hot-plug, como USB, IEEE1394, hot-swappable PCI, ... Qual é o primeiro dispositivo? E por quanto tempo? Qual será o nome dos outros dispositivos quando o primeiro desaparecer? Como irá afetar as transações que estiverem acontecendo? Não seria muito legal se um trabalho de impressão mudasse de sua impressora a laser super-nova para sua impressora matricial quase morta porque sua mãe tirou o plugue da impressora a laser que era a primeira impressora? Aqui entra o udev. As metas do projeto de udev são tão interessantes quanto necessárias:
Para fornecer essas funções, o udev é desenvolvido em três projetos separados: namedev, libsysfs e, claro, udev. O namedev permite que você defina os nomes dos dispositivos à parte do programa udev. Isto permite políticas de nomes flexíveis e esquemas de nomeamento desenvolvidos por entidades separadas. O subsistema de nomeamento de dispositivos fornece uma interface padrão que o udev pode usar. Atualmente só um esquema de nomes é fornecido pelo namedev; o fornecido pela LANANA, usado pela maior parte dos sistema Linux atualmente e portanto muito útil para a maior parte dos usuários de Linux. O namedev usa um procedimento de 5 passos para descobrir o nome de um dispositivo. Se o nome do dispositivo for encontrado nos passos dados, o nome é usado. Os passos são:
O passo número ou etiqueta serial verifica se o dispositivo tem um identificador singular. Por exemplo, dispositivos USB tem um número serial de USB singular; dispositivos SCSI tem um UUID singular. Se o namedev encontrar uma relação entre o número singular e um dado arquivo de configuração, o nome fornecido no arquivo de configuração é usado. O passo número do bus de dispositivo verifica número do bus de dispositivo. Para ambientes sem hot-swap o procedimento é suficiente para identificar um dispositivo de hardware. Por exemplo, números de BUS de PCI raramente mudam durante a vida de um sistema. Novamente, se o namedev encontrar uma relação entre esta posição e o dado arquivo de configuração, o nome fornecido no arquivo de configuração é usado. De forma semelhante, a topologia de bus é um jeito estático de definir dispositivos contanto que o usuário não os mude. Quando a posição dispositivo bater com um ajuste dado pelo usuário, o nome que acompanha é usado. O quarto passo, nome dado estaticamente, é uma simples troca de nomes. Quando o nome do kernel (o nome padrão) bater com uma expressão de troca, o nome substituto será usado. O passo final (nome dado pelo kernel) é um pega-tudo: ele pega o nome padrão dado pelo kernel. Na maioria dos casos isso é suficiente já que bate com os nomes dos dispositivos usados em sistemas Linux atuais. O udev interage com o kernel através do pseudo sistema de arquivos sysfs. O projeto libsysfs fornece uma API comum para acessar informações através do sistema de arquivos sysfs de modo genérico. Isto permite trabalhar com todos tipos de hardware sem ter que presumir que tipo de hardware será usado. Toda vez que o kernel percebe uma mudança na estrutura de dispositivos, ele chama o programa /sbin/hotplug. O hotplug roda a aplicação linkada no diretório /etc/hotplug.d/default, onde você também encontrará um link simbólico para aplicação udev. O hotplug dirige a informação dada pelo kernel para a aplicação udev que toma as ações necessárias na estrutura de /dev (criando ou destruindo arquivos de dispositivo). O udev é feito para ser usado em combinação com um kernel 2.6 (como vanilla-sources ou gentoo-sources com o profile padrão 2005.0). Se você estiver usando um desses kernéis, então você só tem que certificar-se de que você tem uma versão recente de sys-apps/baselayout É tudo de que você precisa.
O udev irá instalar o hotplug-base como uma de suas dependências. Você não precisa instalar o hotplug se você não quer seus módulos sejam carregados automaticamente quando você plugar dispositivos. O hotplug também lida com o levante automático de dispositivos de rede e baixar firmwares.
Se você quiser módulos carregados para dispositivos que foram plugados antes de você iniciar, use o pacote coldplug:
Não se esqueça de adicionar coldplug ao runlevel boot:
Em relação ao kernel, certifique-se de ativar as seguintes opções:
Você pode deixar o /dev file system support (OBSOLETE) ativo se você desejar, mas certifique-se que "Automatically mount at boot" esteja desligado:
Se você usar o genkernel, não se esqueça de rodá-lo com a opção --udev para ativar as diretivas de configuração de kernel necessárias. A configuração padrão dada pelo comando genkernel é suficiente. Se você quiser usar os ajustes de udev que o Gentoo adicionou para deixar sua vida mais fácil, pare de ler aqui. O Gentoo irá usar o udev, mas manterá um /dev estático para que você nunca tenha nódulos de dispositivos faltando. Os scripts de init do Gentoo não irão rodar o daemon devfsd e irão desligar o devfs quando você iniciar. Mas se você é duro na queda e quer usar um sistema só com udev, sem ajustes como feito pelos desenvolvedores do udev (incluindo as dificuldades de nódulos de sistema faltando porque o udev ainda não os suporta), por favor, leia mais :) Nós iremos desligar as regras para salvar os nódulos de arquivos de dispositivos: edite a variável RC_DEVICE_TARBALL no /etc/conf.d/rc e configure-a como no:
Se você incluiu suporte a devfs no kernel, você pode desativá-lo na configuração do gerenciador de inicialização: adicione gentoo=nodevfs como parâmetro de kernel. Se você quiser usar devfs e desativar udev, adicione gentoo=noudev como parâmetro de kernel. Arquivos de nódulos de dispositivos faltando na inicialização Se você não puder iniciar com sucesso porque você obtém um erro sobre /dev/null não encontrado, ou porque o console inicial está faltando, o problema é que você não tem alguns arquivos de dispositivos que devem estar disponíveis antes do /dev ser montado e gerenciado pelo udev. Isto é comum em máquinas Gentoo instaladas de mídias antigas. Se você estiver rodando sys-apps/baselayout-1.8.12 ou mais recente, o problema é menor, já que o processo de inicialização ainda conseguirá completar. No entanto, para livrar-se desses avisos perturbadores, você deve criar os nódulos de dispositivos como descrito abaixo. Para ver que nódulos de dispositivo estão presentes antes do sistema de arquivos /dev ser montado, rode os seguintes comandos:
Os dispositivos necessários para uma inicialização com sucesso são /dev/null e /dev/console. Se eles não apareceram no teste anterior, você tem que criá-los manualmente. Execute os seguintes comandos no diretório test/dev/:
Quando você terminar, não se esqueça de desmontar o diretório test/:
Se você usa os drivers proprietários da nVidia e o servidor de X não conseguir iniciar em um sistema somente de udev, verifique que você tem:
Se o xorg-x11 se recusar a iniciar, pode ser que o arquivo de dispositivo /dev/nvidia está faltando. Se este for o caso, rode para /sbin/NVmakedevices.sh (re)cria-lo. Quando você usar udev e LVM2 juntos, você pode perceber que seus grupos de volume e volumes lógicos que você criou desapareceram. Bom, eles não desapareceram, mas eles são infelizmente chamados de /dev/dm-# com # sendo 0, 1, ... Para arrumar isso, edite o /etc/udev/rules.d/50-udev.rules e descomente a seguinte linha:
A seguir, instale sys-fs/multipath-tools que contém a aplicação devmap_name.
Falta de consistência de nomes entre DevFS e udev Embora nossa intenção seja ter um esquema de nomes consistente entre as duas soluções de gerenciamento dinâmico de dispositivos, às vezes diferenças de nome acontecem. O problema que nos foi relatado é de um HP Smart Array 5i RAID controller (mais precisamente o módulo de kernel cciss). Com o udev, os dispositivos são chamados de /dev/cciss/cXdYpZ com X, Y e Z sendo números normais. Com o devfs, os dispositivos são /dev/hostX/targetY/partZ, ou um link simbólico de /dev/cciss/cXdY. Se este for o caso, não se esqueça de atualizar seu /etc/fstab e arquivos de configuração de gerenciador de inicialização corretamente. O mesmo acontece com links simbólicos que costumavam existir em /dev, como /dev/mouse, que o udev não cria mais. Tenha certeza de verificar seu arquivo de configuração de X e ver se a regra Device para seu mouse aponta para um arquivo de dispositivo existente. Se os nódulos de dispositivo não são criados quando um módulo é carregado de /etc/modules.autoload.d/kernel-2.6, mas eles aparecem quando você carrega o módulo manualmente com modprobe, então você deve experimentar atualizar para o sys-apps/baselayout-1.8.12 ou mais recente. Suporte para dispositivos de framebuffer (/dev/fb/*) está presente em kernéis começando a partir da versão 2.6.6-rc2. Para kernéis mais antigos que o 2.6.4, você tem que explicitamente incluir suporte para o sistema de arquivos /dev/pts.
A palestra de udev no Linux Symposium (Ottawa, Ontario Canadá - 2003) dada por Greg Kroah-Hartman (IBM Corporation) forneceu uma sólida compreensão da aplicação do udev. Decibel's UDEV Primer é um guia profundo sobre udev e Gentoo. Escrevendo regras de udev pelo desenvolvedor do Gentoo Daniel Drake é um excelente documento para aprender como personalizar sua instalação de udev. O conteúdo deste documento está licenciado pela licença Creative Commons - Attribution / Share Alike. |
|