29 Gerenciamento dinâmico de dispositivos do kernel com udev #

Os nós de dispositivos no diretório /dev concedem acesso aos dispositivos de kernel correspondentes. Com udev, o diretório /dev reflete o estado atual do kernel. Cada dispositivo de kernel tem um arquivo de dispositivo correspondente. Se um dispositivo for desconectado do sistema, o nó de dispositivo será removido.

O conteúdo do diretório /dev será mantido em um sistema de arquivos temporário, e todos os arquivos serão renderizados a cada inicialização do sistema. Arquivos criados ou modificados manualmente por definição não resistem a uma reinicialização. Os diretórios e arquivos estáticos que sempre devem estar no diretório /dev, independentemente do estado do dispositivo de kernel correspondente, podem ser criados com systemd-tmpfiles. Os arquivos de configuração estão em /usr/lib/tmpfiles.d/ e /etc/tmpfiles.d/. Para obter mais informações, consulte a página de manual systemd-tmpfiles(8).

As informações de dispositivo necessárias são exportadas pelo sistema de arquivos sysfs Para cada dispositivo detectado e inicializado pelo kernel, um diretório com o nome do dispositivo é criado. Ele contém arquivos de atributos com propriedades específicas do dispositivo.

Sempre que um dispositivo é adicionado ou removido, o kernel envia um uevent para notificar o udev sobre a mudança. O daemon udev lê e analisa todas as regras dos arquivos /usr/lib/udev/rules.d/*.rules e /etc/udev/rules.d/*.rules na inicialização e os mantém na memória. Se os arquivos de regras forem mudados, adicionados ou removidos, o daemon poderá recarregar sua representação na memória com o comando udevadm control --reload. Para obter mais detalhes sobre as regras do udev e sua sintaxe, consulte a Seção 29.6, “Influenciando o gerenciamento de eventos de dispositivo do kernel com as regras do udev”.

Cada evento recebido é comparado com o conjunto de regras fornecido. As regras podem adicionar ou modificar chaves de ambiente de eventos, solicitar um nome específico a ser criado pelo nó do dispositivo, adicionar links simbólicos apontando para o nó ou adicionar programas a serem executados após a criação do nó do dispositivo. Os uevents de núcleo do driver são recebidos de um soquete netlink do kernel.

Os drivers de barramento de kernel pesquisam dispositivos. Para cada dispositivo detectado, o kernel cria uma estrutura de dispositivo interna enquanto o núcleo do driver envia um uevent ao daemon udev. Dispositivos de barramento se identificam por meio de um ID formatado especialmente, que especifica o tipo de dispositivo. Esses IDs consistem em IDs de produto e fornecedor, além de outros valores específicos do subsistema. Cada barramento tem seu próprio esquema para esses IDs, chamados MODALIAS. O kernel usa as informações do dispositivo, compõe uma string de ID MODALIAS com base nelas e envia essa string junto com o evento. Para um mouse USB, a string tem a seguinte aparência:

MODALIAS=usb:v046DpC03Ed2000dc00dsc00dp00ic03isc01ip02

Cada driver de dispositivo carrega uma lista de álias conhecidos para os dispositivos que pode tratar. A lista está contida no próprio arquivo de módulo de kernel. O programa depmod lê as listas de IDs e cria o arquivo modules.alias no diretório /lib/modules do kernel para todos os módulos disponíveis atualmente. Com essa infraestrutura, carregar o módulo é fácil como chamar modprobe para cada evento com uma chave MODALIAS. Se modprobe $MODALIAS for chamado, ele corresponderá o álias do dispositivo composto para o dispositivo com os álias fornecidos pelos módulos. Se uma entrada correspondente for encontrada, o módulo será carregado. Tudo isso é acionado automaticamente pelo udev.

Todos os eventos de dispositivo que ocorrerem durante o processo de boot antes da execução do daemon udev são perdidos, pois a infraestrutura para processar esses eventos está no sistema de arquivos raiz e não está disponível no momento. Para cobrir essa perda, o kernel fornece um arquivo uevent localizado no diretório de dispositivo de cada dispositivo no sistema de arquivos sysfs. Ao gravar add para esse arquivo, o kernel envia novamente o mesmo evento como o evento perdido durante a inicialização. Um loop simples em todos os arquivos uevent em /sys aciona todos os eventos novamente para criar os nós de dispositivo e executar a configuração do dispositivo.

Por exemplo, durante o boot, um mouse USB talvez não seja inicializado pela lógica de boot anterior, pois o driver não está disponível nesse momento. O evento para a descoberta do dispositivo foi perdido e não encontrou um módulo de kernel para o dispositivo. Em vez de pesquisar manualmente os dispositivos conectados, o udev solicita todos os eventos de dispositivo do kernel após a disponibilização do sistema de arquivos raiz. Dessa forma, o evento para o dispositivo de mouse USB é executado novamente. Então ele encontra o módulo de kernel no sistema de arquivos raiz montado e o mouse USB pode ser inicializado.

No espaço do usuário, não há diferença visível entre a sequência coldplug do dispositivo e a descoberta de dispositivo durante o tempo de execução. Em ambos os casos, as mesmas regras são usadas para correspondência e os mesmos programas configurados são executados.

O programa udevadm monitor pode ser usado para visualizar os eventos centrais do driver e a temporização dos processos de eventos do udev.

UEVENT[1185238505.276660] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1 (usb)
UDEV  [1185238505.279198] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1 (usb)
UEVENT[1185238505.279527] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0 (usb)
UDEV  [1185238505.285573] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0 (usb)
UEVENT[1185238505.298878] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10 (input)
UDEV  [1185238505.305026] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10 (input)
UEVENT[1185238505.305442] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/mouse2 (input)
UEVENT[1185238505.306440] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/event4 (input)
UDEV  [1185238505.325384] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/event4 (input)
UDEV  [1185238505.342257] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/mouse2 (input)

As linhas UEVENT mostram os eventos que o kernel enviou através de netlink. As linhas UDEV mostram os handlers de evento do udev concluídos. A temporização é impressa em microssegundos. O tempo entre UEVENT e UDEV é o tempo que o udev levou para processar este evento ou pelo qual o daemon udev atrasou sua execução para sincronizar esse evento com os eventos relacionados e já em execução. Por exemplo, eventos para partições de disco rígido sempre esperam pela conclusão do evento do dispositivo de disco principal, pois os eventos de partição podem se basear nos dados que o evento de disco principal consultou do hardware.

udevadm monitor --env mostra o ambiente de evento completo:

ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10
SUBSYSTEM=input
SEQNUM=1181
NAME="Logitech USB-PS/2 Optical Mouse"
PHYS="usb-0000:00:1d.2-1/input0"
UNIQ=""
EV=7
KEY=70000 0 0 0 0
REL=103
MODALIAS=input:b0003v046DpC03Ee0110-e0,1,2,k110,111,112,r0,1,8,amlsfw

O udev também envia mensagens para o syslog. A prioridade do syslog padrão que controla as mensagens que são enviadas ao syslog está especificada no arquivo de configuração /etc/udev/udev.conf do udev. A prioridade de registro do daemon em execução pode ser modificada com udevadm control --log_priority=LEVEL/NUMBER.

Uma regra do udev pode corresponder a qualquer propriedade que o kernel adiciona ao evento propriamente dito ou a qualquer informação que o kernel exporta para sysfs. A regra também pode solicitar informações adicionais de programas externos. Os eventos são comparados a todas as regras fornecidas nos diretórios /usr/lib/udev/rules.d/ (para regras padrão) e /etc/udev/rules.d (configuração específica do sistema).

Cada linha no arquivo de regras contém pelo menos um par de valores de chave. Há dois tipos de chaves, de atribuição e correspondência. Se todas as chaves de correspondência corresponderem aos valores, a regra será aplicada e as chaves de atribuição serão atribuídas ao valor especificado. Uma regra correspondente pode especificar o nome do nó do dispositivo, adicionar links simbólicos apontando para o nó ou executar um programa especificado como parte do gerenciamento de eventos. Se nenhuma regra de correspondência for encontrada, o nome do nó de dispositivo padrão será usado para criar o nó de dispositivo. Informações detalhadas sobre a sintaxe de regra e as chaves fornecidas para correspondência ou importação de dados estão descritas na página de manual do udev. As regras de exemplo a seguir apresentam uma introdução básica à sintaxe da regra do udev. As regras de exemplo são todas extraídas do conjunto de regras padrão /usr/lib/udev/rules.d/50-udev-default.rules do udev.

# console
KERNEL=="console", MODE="0600", OPTIONS="last_rule"

# serial devices
KERNEL=="ttyUSB*", ATTRS{product}=="[Pp]alm*Handheld*", SYMLINK+="pilot"

# printer
SUBSYSTEM=="usb", KERNEL=="lp*", NAME="usb/%k", SYMLINK+="usb%k", GROUP="lp"

# kernel firmware loader
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware.sh"

A regra console consiste em três chaves: uma chave de correspondência (KERNEL) e duas chaves de atribuição (MODE e OPTIONS). A regra de correspondência KERNEL pesquisa qualquer item do tipo console na lista de dispositivos. Apenas correspondências exatas são válidas e acionam essa regra para que seja executada. A chave MODE atribui permissões especiais ao nó do dispositivo, neste caso, permissões de leitura e gravação apenas ao proprietário desse dispositivo. A chave OPTIONS torna esta a última regra a ser aplicada a qualquer dispositivo desse tipo. Qualquer regra posterior que corresponda a esse tipo de dispositivo em particular não terá nenhum efeito.

A regra dos serial devices não está mais disponível em 50-udev-default.rules, mas ainda vale a pena ser considerada. Ela consiste em duas chaves de correspondência (KERNEL e ATTRS) e uma chave de atribuição (SYMLINK). A chave KERNEL procura todos os dispositivos do tipo ttyUSB. Usando o curinga *, essa chave corresponde a diversos desses dispositivos. A segunda chave de correspondência, ATTRS, verifica se o arquivo de atributo do product em sysfs para qualquer dispositivo ttyUSB contém uma determinada string. A chave de atribuição (SYMLINK) aciona a adição de um link simbólico para esse dispositivo em /dev/pilot. O operador usado nessa chave (+=) instrui o udev a executar essa ação adicionalmente, mesmo se regras anteriores ou posteriores adicionarem outros links simbólicos. Como essa regra contém duas chaves de correspondência, ela é aplicada apenas se ambas as condições são cumpridas.

A regra printer lida com impressoras USB e contém duas chaves de correspondência que devem ser aplicadas para que a regra inteira seja aplicada (SUBSYSTEM e KERNEL). Três chaves de atribuição lidam com a nomeação desse tipo de dispositivo (NAME), a criação dos links de dispositivo simbólicos (SYMLINK) e a participação no grupo desse tipo de dispositivo (GROUP). O uso do curinga * na chave KERNEL faz com que ela corresponda a diversos dispositivos de impressora lp. Substituições são usadas nas duas chaves, NAME e SYMLINK, para estender essas strings pelo nome do dispositivo interno. Por exemplo, o link simbólico para a primeira impressora USB lp seria /dev/usblp0.

A regra do kernel firmware loader faz com que o udev carregue um firmware adicional por um script de assistente externo durante o tempo de execução. A chave de correspondência SUBSYSTEM procura o subsistema de firmware A chave ACTION verifica se algum dispositivo pertencente ao subsistema de firmware foi adicionado. A chave RUN+= aciona a execução do script firmware.sh para localizar o firmware a ser carregado.

Características gerais são comuns a todas as regras:

O diretório de dispositivo dinâmico e a infraestrutura de regras do udev permitem fornecer nomes estáveis para todos os dispositivos de disco, independentemente da ordem de reconhecimento ou da conexão usada para o dispositivo. Cada dispositivo de bloco apropriado criado pelo kernel é examinado por ferramentas com conhecimento especial sobre determinados barramentos, tipos de unidade ou sistemas de arquivos. Com o nome do nó do dispositivo fornecido pelo kernel dinâmico, o udev mantém as classes de links persistentes apontando para o dispositivo:

/dev/disk
|-- by-id
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B -> ../../sda
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part1 -> ../../sda1
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part6 -> ../../sda6
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part7 -> ../../sda7
|   |-- usb-Generic_STORAGE_DEVICE_02773 -> ../../sdd
|   `-- usb-Generic_STORAGE_DEVICE_02773-part1 -> ../../sdd1
|-- by-label
|   |-- Photos -> ../../sdd1
|   |-- SUSE10 -> ../../sda7
|   `-- devel -> ../../sda6
|-- by-path
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part6 -> ../../sda6
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part7 -> ../../sda7
|   |-- pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sr0
|   |-- usb-02773:0:0:2 -> ../../sdd
|   |-- usb-02773:0:0:2-part1 -> ../../sdd1
`-- by-uuid
    |-- 159a47a4-e6e6-40be-a757-a629991479ae -> ../../sda7
    |-- 3e999973-00c9-4917-9442-b7633bd95b9e -> ../../sda6
    `-- 4210-8F8C -> ../../sdd1

Os seguintes arquivos e diretórios contêm os elementos cruciais da infraestrutura do udev:

Para obter mais informações sobre a infraestrutura do udev, consulte as seguintes páginas de manual: