9.4. Gerenciando Dispositivos

9.4.1. Dispositivos da Rede de Comunicação

O Udev, por padrão, nomeia dispositivos da rede de comunicação de acordo com dados de Firmware/BIOS ou características físicas, como o barramento, slot ou endereço MAC. O propósito dessa convenção de nomenclatura é o de garantir que dispositivos da rede de comunicação sejam nomeados consistentemente e não baseados em quando a placa de rede de comunicação foi descoberta. Em versões mais antigas do Linux—em um computador com duas placas de rede de comunicação feitas por Intel e Realtek, por exemplo—a placa de rede de comunicação fabricada pela Intel talvez se torne eth0, enquanto que e a placa Realtek se tornou eth1. Depois de uma reinicialização, as placas poderiam, às vezes, serem renumeradas da maneira inversa.

No novo esquema de nomenclatura, nomes típicos de dispositivo da rede de comunicação são alguma coisa como enp5s0 ou wlp3s0. Se essa convenção de nomenclatura não for desejada, [então] o esquema de nomenclatura tradicional, ou um esquema personalizado, pode ser implementado.

9.4.1.2. Criando Regras Personalizadas do Udev

O esquema de nomenclatura pode ser personalizado criando-se regras personalizadas do Udev. Um script foi incluído que gera as regras iniciais. Gere essas regras executando:

bash /usr/lib/udev/init-net-rules.sh

Agora, inspecione o arquivo /etc/udev/rules.d/70-persistent-net.rules, para descobrir qual nome foi atribuído a qual dispositivo da rede de comunicação:

cat /etc/udev/rules.d/70-persistent-net.rules

Nota

Em alguns casos, tais como quando endereços MAC tenham sido atribuídos para uma placa de rede de comunicação manualmente, ou em um ambiente virtual, como Qemu ou Xen, o arquivo das regras da rede de comunicação possivelmente não seja gerado, pois endereços não são atribuídos consistentemente. Nesses casos, esse método não pode ser usado.

O arquivo começa com um bloco de comentário seguido por duas linhas para cada NIC. A primeira linha para cada NIC é uma descrição comentada mostrando os IDs de hardware delas (por exemplo, fornecedor(a) de PCI delas e IDs de dispositivo, se ela for uma placa PCI), juntamente com o controlador delas (entre parênteses, se o controlador puder ser encontrado). Nem o ID de hardware, nem o controlador, é usado para determinar quais nomes dar para uma interface; essa informação é somente para referência. A segunda linha é a regra do Udev que corresponde a essa NIC e atualmente atribui a ela um nome.

Todas as regras do Udev são compostas de várias palavras chave, separadas por vírgulas e espaços em branco opcionais. Aqui estão as palavras chave e uma explicação de cada uma:

• SUBSYSTEM=="net" - Isso diz ao Udev para ignorar dispositivos que não sejam placas da rede de comunicação.

• ACTION=="add" - Isso diz ao Udev para ignorar essa regra para um uevent que não seja um adicionar (uevents "remover" e "mudar" também acontecem, porém não precisam renomear interfaces da rede de comunicação).

• DRIVERS=="?*" - Isso existe, de forma que o Udev ignorará sub-interfaces VLAN ou bridge (pois essas sub-interfaces não tem controladores). Essas sub-interfaces são puladas, pois o nome que seria atribuído conflitaria com os dispositivos ancestrais delas.

• ATTR{address} - O valor dessa palavra chave é o endereço MAC da NIC.

• ATTR{type}=="1" - Isso garante que a regra corresponda somente à interface primária no caso de certos controladores sem fios os quais criam múltiplas interfaces virtuais. As interfaces secundárias são puladas pela mesma razão que sub-interfaces VLAN e bridge são puladas: existiria um conflito de nome do contrário.

• NAME - O valor dessa palavra chave é o nome que o Udev atribuirá para essa interface.

O valor de NAME é a parte importante. Assegure-se de que você sabe qual nome foi atribuído para cada uma das suas placas da rede de comunicação antes de prosseguir, e tenha certeza de usar esse valor NAME quando criar seus arquivos de configuração da rede de comunicação.

Mesmo se o arquivo de regras personalizadas do "udev" for criado, o "udev" possivelmente ainda atribuirá um ou mais nomes alternativos para uma "NIC" baseados nas características físicas. Se uma regra personalizada do "udev" renomeasse alguma "NIC" usando um nome já atribuído como um nome alternativo de outra "NIC", [então] essa regra do "udev" falharia. Se esse problema ocorrer, [então] você poderá criar o arquivo de configuração "/etc/udev/network/99-default.link" com uma política de atribuição alternativa vazia, substituindo o arquivo de configuração padrão "/usr/lib/ udev/network/99-default.link":

sed -e '/^AlternativeNamesPolicy/s/=.*$/=/'  \
       /usr/lib/udev/network/99-default.link \
     > /etc/udev/network/99-default.link

9.4.2. Links Simbólicos de CD-ROM

Alguns aplicativos que você possivelmente queira instalar posteriormente (por exemplo, vários reprodutores de mídia) esperam que os links simbólicos /dev/cdrom e /dev/dvd existam, e apontem para um dispositivo de CD-ROM ou de DVD-ROM. Também, possivelmente seja conveniente colocar referências a esses links simbólicos em /etc/fstab. O Udev vem com um script que gerará arquivos de regras para criar esses links simbólicos para você, dependendo dos recursos de cada dispositivo, mas você precisa decidir qual dos dois modos de operação você deseja ter para o script usar.

Primeiro, o script pode operar em modo “por-caminho” (usado por padrão para dispositivos USB e FireWire), onde as regras que ele cria dependem do caminho físico para o dispositivo de CD ou de DVD. Segundo, ele pode operar em modo “por-id” (padrão para dispositivos IDE e SCSI), onde as regras que ele cria dependem das sequências de caracteres de identificação armazenadas no próprio dispositivo de CD ou de DVD. O caminho é determinado pelo script path_id do Udev, e as sequências de caracteres de identificação são lidas a partir do hardware pelos aplicativos ata_id ou scsi_id dele, dependendo de qual tipo de dispositivo você tenha.

Existem vantagens para cada abordagem; a abordagem correta depende de que tipos de mudanças de dispositivo possivelmente aconteçam. Se você espera o caminho físico para o dispositivo (isto é, as portas e (ou) slots aos quais ele se pluga) mudar, por exemplo porque você planeja mover a unidade para uma porta IDE diferente ou um conector USB diferente, então você deveria usar o modo “por-id”. Por outro lado, se você espera que a identificação do dispositivo mude, por exemplo porque ele possivelmente morra, e você pretende substitui-lo por um dispositivo diferente que pluga nos mesmos conectores, então você deveria usar o modo “por-caminho”.

Se ambos os tipos de mudanças são possíveis com a sua unidade, então escolha um modo baseado no tipo de mudança que você espera acontecer mais frequentemente.

Importante

Dispositivos externos (por exemplo, uma unidade de CD conectada via USB) não deveria usar persistência por caminho, porque cada vez que o dispositivo for plugado em uma nova porta externa, o caminho físico dele mudará. Todos os dispositivos conectados externamente terão esse problema se você escrever regras do Udev para reconhecê-los pelo caminho físico deles; o problema não está limitado a unidades de CD e de DVD.

Se você deseja ver os valores que os scripts do Udev usarão, então para o dispositivo apropriado de CD-ROM, encontre o diretório correspondente sob /sys (por exemplo, isso pode ser /sys/block/hdd) e execute um comando similar ao seguinte:

udevadm test /sys/block/hdd

Olhe para as linhas contendo a saída gerada de vários aplicativos *_id. O modo “por-id” usará o valor ID_SERIAL se ele existir e não estiver vazio; do contrário ele usará uma combinação de ID_MODEL e ID_REVISION. O modo “por-caminho” usará o valor ID_PATH.

Se o modo padrão não for adequado para a sua situação, então a seguinte modificação pode ser feita para o arquivo /etc/udev/rules.d/83-cdrom-symlinks.rules, como se segue (onde mode é um de “por-id” ou “por-caminho”):

sed -e 's/"write_cd_rules"/"write_cd_rules mode"/' \
    -i /etc/udev/rules.d/83-cdrom-symlinks.rules

Observe que não é necessário criar os arquivos de regras ou links simbólicos neste momento, porque você montou vinculadamente o diretório do sistema anfitrião /dev dentro do sistema LFS, e nós assumimos que os links simbólicos existem no anfitrião. As regras e links simbólicos serão criados na primeira vez que você inicializar seu sistema LFS.

Entretanto, se você tiver múltiplos dispositivos de CD-ROM, então os links simbólicos gerados naquele momento possivelmente apontem para dispositivos diferentes dos que eles apontam em seu anfitrião, porque os dispositivos não são descobertos em uma ordem previsível. As atribuições criadas quando você inicializar o sistema LFS pela primeira vez serão estáveis, de forma que isso é um problema somente se você precisar dos links simbólicos em ambos os sistemas para apontarem para o mesmo dispositivo. Se você precisar disso, então inspecione (e possivelmente edite) o arquivo /etc/udev/rules.d/70-persistent-cd.rules gerado após a inicialização, para ter certeza que os links simbólicos atribuídos correspondem às suas necessidades.

9.4.3. Lidando com Dispositivos Duplicados

Como explicado na Seção 9.3, “Visão Geral do Manuseio de Dispositivo e de Módulo,” a ordem na qual dispositivos com a mesma função aparecem em /dev é essencialmente aleatória. Por exemplo, se você tiver uma câmera web USB e um sintonizador de TV, às vezes /dev/video0 se referirá à câmera e /dev/video1 se referirá ao sintonizador; e às vezes depois de uma reinicialização a ordem mudará. Para todas as classes de hardware, exceto placas de som e placas de rede de intercomunicação, isso é corrigível criando-se regras do udev para criar links simbólicos persistentes. O caso das placas de rede de intercomunicação está abrangido separadamente na Seção 9.5, “Configuração Geral da Rede de Comunicação,” e configuração de placa de som pode ser encontrado no BLFS.

Para cada um dos seus dispositivos que é provável ter esse problema (mesmo que o problema não exista em sua distribuição atual Linux), encontre o diretório correspondente sob /sys/class ou /sys/block. Para dispositivos de vídeo, isso possivelmente seja /sys/class/video4linux/videoX. Descubra os atributos que identificam o dispositivo de maneira única (geralmente, IDs de fornecedor(a) e produto e (ou) números seriais funcionam):

udevadm info -a -p /sys/class/video4linux/video0

Então escreva regras que criam os links simbólicos, por exemplo:

cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"

# Links simbólicos persistentes para webcam e sintonizador
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", SYMLINK+="webcam"
KERNEL=="video*", ATTRS{device}=="0x036f",  ATTRS{vendor}=="0x109e", SYMLINK+="tvtuner"

EOF

O resultado é que os dispositivos /dev/video0 e /dev/video1 ainda se referem aleatoriamente ao sintonizador e à câmera web (e, portanto, nunca deveriam ser usados diretamente), mas existem links simbólicos /dev/tvtuner e /dev/webcam que sempre apontam para o dispositivo correto.