O daemon udev gerencia o sistema de arquivos /dev. Permite que você identifique dispositivos com base em suas propriedades, como ID do(a) fornecedor(a) ou ID do dispositivo, de forma dinâmica. É executado no espaço de usuário(a) e foi introduzido no [[LinuxKernel|Linux] 2.6.
Contents
Visão geral
O sistema udev é composto por alguns serviços do núcleo (kernel) e o daemon udevd. O núcleo informa o daemon quando eventos relacionados ao hardware acontecem. O daemon responde a eventos com ações apropriadas, que acontecem no espaço de usuário(a), com base em "regras" udev configuráveis. A funcionalidade de espaço de usuário(a) do udev é implementada pelo systemd-udevd.service.
O udev usa regras para determinar qual nome de dispositivo é dado a cada peça de hardware. Isso significa que o dispositivo receberá o mesmo nome, independentemente de qual porta está conectado. Por exemplo, uma regra pode dizer que um disco rígido com o fabricante "iRiver" e o código do dispositivo "ABC" será sempre montado como /dev/iriver. A nomeação consistente de dispositivos garante que os scripts dependentes da existência de um dispositivo específico não serão quebrados.
Na inicialização, o udev lê sua configuração e arquivos de regras na memória. Quando um evento acontece, ele verifica seu banco de dados de regras e executa as ações apropriadas: embora alguns documentos se concentrem na criação de dispositivos em resposta a novos dispositivos que apareceram (hotplugging - "conexão a quente", conexão em fucionamento), as regras do udev podem ser mais gerais: o udev pode executar comandos de espaço de usuário(a) arbitrários em resposta a vários eventos que recebe do kernel. (dar um exemplo disso?)
Configuração
De qual lugar as regras são lidas
O arquivo de configuração principal está em /etc/udev/udev.conf, e as regras são lidas a partir de /run/udev/rules.d, /etc/udev/rules.d e /lib/udev/rules.d: Se um arquivo com o mesmo nome de base estiver presente em mais de um desses diretórios, as versões posteriores serão ignoradas. A ideia é que os pacotes devem instalar as regras em /lib/udev/rules.d, e que o(a) administrador(a) possa substituí-las colocando arquivos em /etc (ou /run para experimentos temporários).
As regras são lidas em ordem alfabética e devem terminar com ".rules".
Quando o arquivo de configuração ou os arquivos de regras são alterados, o programa udevadm deve ser usado para instruir systemd-udevd para recarregar as regras (veja abaixo).
Sintaxe das regras
as regras (rules) contêm uma linha (linhas podem ser quebradas com uma \ antes de uma nova linha).
- as regras consistem em "matches" (correspondências) e "actions" (ações).
- matches e actions são trios "key" "operator" "value" (chave, operador, valor).
- matches têm == ou != para operadores.
- actions têm = (atribuição) para operador.
- matches verificam um ou mais atributos do evento para ver se a ação será aplicada.
- actions especificam o que vai acontecer.
correspondência de exemplo: BUS=="usb"
ação de exemplo: NAME="mydev"
- regra de exemplo: {{
KERNEL=="sd*[0-9]|dasd*[0-9]", ENV{ID_SERIAL}=="?*", \
- SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
}}}
- todas as regras de correspondência serão disparadas.
- regras anteriores têm precedência sobre regras posteriores - então coloque suas personalizações antes na lista de arquivos rules.d.
- ações como chave="valor" sobrescrevem.
ações como chave+="valor" adicionam às ações que são executadas, por exemplo SYMLINK+="foo" significa "além de quaisquer outros links simbólicos que você iria fazer para este evento, também faça um link simbólico chamado foo".
Conjuntos de regras
Regras para conjuntos de regras (rules sets):
- Todas as regras estão em um grande espaço de regras, embora sejam divididas em vários arquivos.
A única organização no espaço de regras é a capacidade de definir rótulos (labels) e, em seguida, pular um monte de regras durante "combine esse evento com essas regras" ao avançar com uma ação GOTO.
há um outro tipo de regra chamado "label" (rótulo): por exemplo, LABEL="persistent_storage_end". São usadas por regras regulares que têm ações "GOTO", por exemplo:
ACTION!="add", GOTO="persistent_storage_end"
Note que nesta regra, o termo ACTION é um atributo de um evento e está sendo usado como condição para decidir se a ação GOTO será acionada.- É educado manter GOTOS para saltar dentro de um arquivo (ou você terá que se preocupar em reordenar os arquivos).
- Não pule para trás para um rótulo (não tentei, mas imagine que pode terminar em um loop infinito? Talvez o código udev verifique isso - mas se pode ser ignorado (na melhor das hipóteses), por que se incomodar?).
- Você pode definir variáveis no espaço ENV em regras anteriores e se referir a elas com regras posteriores.
Existe uma facilidade para a criação de regras dinâmicas (exemplo: veja z45_persistent-net-generator.rules).
Lista de bloqueio
Consulte ListaDeBloqueioDeMódulosDoKernel
Exemplo: nomeação persistente de dispositivo
Neste exemplo, garantimos que uma placa 3G receba um nome persistente.
1. Conecte a "placa" (ou dispositivo).
Assumimos que foi reconhecida como /dev/ttyS1.
2. Encontre os atributos udev usando udevadm.
udevadm começa com o dispositivo especificado (aqui /dev/ttyS1) e caminha até a cadeia de dispositivos superiores. Ele imprime, para cada dispositivo encontrado, todos os atributos possíveis no formato de regras do udev.
Uma regra para corresponder ao dispositivo pode então ser criada usando os atributos do dispositivo e um de seus superiores.
$ udevadm info --name=/dev/ttyS1 --attribute-walk looking at device '/class/tty/ttyS1': KERNEL=="ttyS1" SUBSYSTEM=="tty" DRIVER=="" ATTR{dev}=="4:65" looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:15:00.0/0.0': KERNELS=="0.0" SUBSYSTEMS=="pcmcia" DRIVERS=="serial_cs" ATTRS{modalias}=="pcmcia:m00A4c1AAFf02fn00pfn00pa32607776pbD9E73B13pcAF9C4D7Fpd00000000" ATTRS{prod_id3}=="NRM6831" ATTRS{prod_id2}=="Merlin UMTS Modem" ATTRS{prod_id1}=="Novatel Wireless" ATTRS{card_id}=="0x1aaf" ATTRS{manf_id}=="0x00a4" ATTRS{func_id}=="0x02" ATTRS{pm_state}=="on" ATTRS{function}=="0x00" looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:15:00.0': KERNELS=="0000:15:00.0" SUBSYSTEMS=="pci" DRIVERS=="yenta_cardbus" ATTRS{msi_bus}=="1" ATTRS{broken_parity_status}=="0" ATTRS{enable}=="2" ATTRS{numa_node}=="0" ATTRS{modalias}=="pci:v00001180d00000476sv000017AAsd000020C6bc06sc07i00" ATTRS{local_cpus}=="00000003" ATTRS{irq}=="16" ATTRS{class}=="0x060700" ATTRS{subsystem_device}=="0x20c6" ATTRS{subsystem_vendor}=="0x17aa" ATTRS{device}=="0x0476" ATTRS{vendor}=="0x1180" looking at parent device '/devices/pci0000:00/0000:00:1e.0': KERNELS=="0000:00:1e.0" SUBSYSTEMS=="pci" DRIVERS=="" ATTRS{msi_bus}=="1" ATTRS{broken_parity_status}=="0" ATTRS{enable}=="1" ATTRS{numa_node}=="0" ATTRS{modalias}=="pci:v00008086d00002448sv00000000sd00000000bc06sc04i01" ATTRS{local_cpus}=="00000003" ATTRS{irq}=="0" ATTRS{class}=="0x060401" ATTRS{subsystem_device}=="0x0000" ATTRS{subsystem_vendor}=="0x0000" ATTRS{device}=="0x2448" ATTRS{vendor}=="0x8086" looking at parent device '/devices/pci0000:00': KERNELS=="pci0000:00" SUBSYSTEMS=="" DRIVERS=="" ATTRS{uevent}==""
3. Crie um arquivo de regras em /etc/udev/rules.d
Tipicamente, você nomearia esse arquivo z21_persistent-local.rules:
ATTRS{prod_id2}=="Merlin UMTS Modem", ATTRS{prod_id1}=="Novatel Wireless", SYMLINK+="MerlinUMTS" ## Alternatively we could use : # ATTRS{card_id}=="0x1aaf", ATTRS{manf_id}=="0x00a4", SYMLINK+="MerlinUMTS"
4. Diga ao udev para recarregar suas regras (ou você pode fazer um reboot):
udevadm control --reload-rules udevadm test -a -p $(udevadm info -q path -n /dev/ttyS1)
Veja também
semu5 em comp.os.linux.questions para um exemplo mais detalhado
http://reactivated.net/writing_udev_rules.html - Escrevendo regras udev
CategorySystemAdministration | CategoryBootProcess | CategoryHardware