Gentoo Logo

Aviso : Este documento não é válido e não é mais mantido.


Guia de udev do Gentoo

Conteúdo:

1.  O que é o udev?

O diretório /dev

Quando 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:

  • Roda em espaço de usuário
  • Cria/remove arquivos de dispositivo dinamicamente
  • Fornece nomes consistentes
  • Fornece uma API em espaço de usuário

Para fornecer essas funções, o udev é desenvolvido em três projetos separados: namedev, libsysfs e, claro, udev.

namedev

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:

  • número ou etiqueta serial
  • número do bus de dispositivo
  • topologia de bus
  • nome dado estaticamente
  • nome dado pelo kernel

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.

libsysfs

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.

udev

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).

2.  Usando o udev no Gentoo

Requisitos

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.

Listagem de código 2.1: Instalando o udev

# emerge udev

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.

Listagem de código 2.2: Instalando scripts opcionais de hotplug

# emerge hotplug

Se você quiser módulos carregados para dispositivos que foram plugados antes de você iniciar, use o pacote coldplug:

Listagem de código 2.3: Instalando o pacote coldplug

# emerge coldplug

Não se esqueça de adicionar coldplug ao runlevel boot:

Listagem de código 2.4: Adicionando coldplug ao runlevel boot

# rc-update add coldplug boot

Em relação ao kernel, certifique-se de ativar as seguintes opções:

Listagem de código 2.5: Opções de kernel necessárias

General setup --->
  [*] Support for hot-pluggable devices

File systems --->
  Pseudo filesystems --->
    [*] /proc file system support
    [*] Virtual memory file system support (former shm fs)

Você pode deixar o /dev file system support (OBSOLETE) ativo se você desejar, mas certifique-se que "Automatically mount at boot" esteja desligado:

Listagem de código 2.6: Não montar o devfsd automaticamente

File systems --->
  Pseudo Filesystems --->
    [*] /dev file system support (OBSOLETE)
      [ ]   Automatically mount at boot

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.

Configuração

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:

Listagem de código 2.7: /etc/conf.d/rc

RC_DEVICE_TARBALL="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.

3.  Problemas conhecidos

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:

Listagem de código 3.1: Listando nódulos de dispositivos disponíveis na inicialização

# mkdir test
# mount --bind / test
# cd test/dev
# ls

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/:

Listagem de código 3.2: Criando os arquivos de nódulos de dispositivo necessários

# mknod -m 660 console c 5 1
# mknod -m 660 null c 1 3

Quando você terminar, não se esqueça de desmontar o diretório test/:

Listagem de código 3.3: Desmontando o diretório test/

# cd ../..
# umount test
# rmdir test

udev e nvidia

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:

  • o módulo nvidia listado em /etc/modules.autoload.d/kernel-2.6
  • uma versão do nvidia-kernel igual ao maior ao media-video/nvidia-kernel-1.0.5336-r2
  • uma versão do baselayout igual ou maior ao sys-apps/baselayout-1.8.12

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.

Nomes de LVM2 desaparecem

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:

Listagem de código 3.4: Descomente essa linha do /etc/udev/rules.d/50-udev.rules

KERNEL="dm-[0-9]*",     PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c"

A seguir, instale sys-fs/multipath-tools que contém a aplicação devmap_name.

Listagem de código 3.5: Instalando multipath-tools

(Na época desta escrita, multipath-tools só está disponível no ramo de testes:)
# echo "=sys-fs/multipath-tools-0.4.2 ~x86" >> /etc/portage/package.keywords
# emerge multipath-tools

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.

Outros problemas

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.

Listagem de código 3.6: Ativando o sistema de arquivos /dev/pts

File systems --->
  Pseudo filesystems --->
    [*] /dev/pts file system for Unix98 PTYs

4.  Recursos & reconhecimentos

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.



Imprimir

Atualizado 5 de janeiro de 2006

A versão original desta tradução não é mais mantida

Resumo: Este documento explica o que é o udev e como você pode usá-lo para atender às suas necessidades.

Sven Vermeulen
Autor

Gregorio Guidi
Colaborador

Marcelo Góes
Tradutor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.