Os nós de dispositivo no diretório /dev fornecem 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. Diretórios e arquivos estáticos que sempre devem estar presentes 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 em /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 especificadas nos arquivos /etc/udev/rules.d/*.rules uma vez na inicialização e as mantém na memória. Se os arquivos de regras são mudados, adicionados ou removidos, o daemon pode recarregar a representação na memória de todas as regras com o comando udevadm control reload_rules. Para obter mais detalhes sobre as regras do udev e sua sintaxe, consulte a Seção 17.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 através de um ID formatado especialmente, que informa o tipo de dispositivo. Geralmente 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 toma as informações do dispositivo, compõe uma string de ID MODALIAS a partir dele 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 ID 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 ocorrem durante o processo de boot antes da execução do daemon udev são perdidos, pois a infraestrutura para gerenciar esses eventos reside no sistema de arquivos raiz e não está disponível naquele 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 pelos dispositivos que podem estar 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 udev levou para processar esse evento ou que o daemon udev atrasou sua execução para sincronizar esse evento com 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 syslog padrão que controla as mensagens que são enviadas ao syslog é especificada no arquivo de configuração do udev /etc/udev/udev.conf. A prioridade de registro do daemon em execução pode ser modificada com udevcontrol 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. Cada evento é correspondido com as regras fornecidas. Essas regras estão localizadas no diretório /etc/udev/rules.d.

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. As informações detalhadas sobre a sintaxe da regra e as chaves fornecidas para corresponder ou importar os 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 foram todas tiradas do conjunto de regras padrão do udev localizado em /etc/udev/rules.d/50-udev-default.rules.

# 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 do console consiste em três chaves: uma chave de correspondência (KERNEL) e duas chaves de atribuição (MODE, 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ó de 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 dispositivos seriais não está mais disponível em 50-udev-default.rules, mas ainda vale a pena ser considerada. Consiste em duas chaves de correspondência (KERNEL e ATTRS) e uma 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 atribuição do produto 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 (+=) diz ao udev para 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 da impressora 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 pelo nome do dispositivo interno tanto na chave NAME quanto na SYMLINK para estender essas strings. Por exemplo, o link simbólico para a primeira impressora USB lp seria /dev/usblp0.

A regra do carregador de firmware do kernel faz o udev carregar 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.

Algumas características são comuns a todas as regras:

O diretório do dispositivo dinâmico e a infraestrutura de regras do udev possibilitam especificar 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 arquivos e os diretórios a seguir incluem elementos cruciais da infraestrutura do udev:

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