Udev - Funcionamento e Regras

Este artigo tem como objetivo entender o UDEV e aplicar regras utilizando o mesmo.

[ Hits: 48.073 ]

Por: Perfil removido em 22/10/2012


Regras do udev



O udev é muito poderoso quanto à aplicação das regras, pois permite desde nomear um dispositivo até executar aplicações, e/ou scripts quando conectamos ou desconectamos, ou quando o dispositivo é alterado.

Para aplicar tais regras, é necessário ter informações obtidas através das chaves de cada device.

Os arquivos que contém as regras do udev estão contidos no diretório /etc/udev/rules.d e devem ter a extensão ".rules", caso algum arquivo dentro do diretório não use essa extensão, o seu conteúdo não será processado.

Eles são lidos em ordem numérico alfabética, por exemplo: se dentro do diretório /etc/udev/rules.d, temos os arquivos "025_usb- regras.rules" e "035_usb-regras.rules", o arquivo "025_usb-regras.rules" será lido antes que o "035_usb-regras.rules".

Agora, sintaxe das regras e exemplos de regras que funcionam e não funcionam.

Cada arquivo com extensão ".rules" tem regras que seguem a seguinte sintaxe:

<chave de combinação>, <chave de combinação e ou chave de atributo>, <Ação>


Para obter as informações de cada chave dos devices, usamos o comando udevadm para pegar um relatório.

Não vou entrar em detalhes de uso do comando, mas deixo o link para o manual:
Será usado, para extrair o relatório, a opção "info" que é utilizada para obter informações e "-p", que indica a localização do dispositivo, e "-a" irá listar informações das propriedades do dispositivo.

Vou listar as propriedades do arquivo de dispositivo /dev/sdc1 que é meu pendrive da SanDisk, usando o comando udevadm como root:

# udevadm info -a -p $(udevadm info -q path -n /dev/sdc1)

looking at device '/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0/net/wlan0':
  KERNEL=="wlan0"
  SUBSYSTEM=="net"
  DRIVER==""
  ATTR{addr_assign_type}=="0"
  ATTR{addr_len}=="6"
  ATTR{dev_id}=="0x0"
  ATTR{ifalias}==""
  ATTR{iflink}=="5"
  ATTR{ifindex}=="5"
  ATTR{type}=="1"
  ATTR{link_mode}=="1"
  ATTR{address}=="00:1a:3f:7c:2e:f4"
  ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
  ATTR{carrier}=="0"
  ATTR{dormant}=="0"
  ATTR{operstate}=="down"
  ATTR{mtu}=="1500"
  ATTR{flags}=="0x1003"
  ATTR{tx_queue_len}=="1000"
  ATTR{netdev_group}=="0"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0':
  KERNELS=="1-8:1.0"
  SUBSYSTEMS=="usb"
  DRIVERS=="ath9k_htc"
  ATTRS{bInterfaceNumber}=="00"
  ATTRS{bAlternateSetting}==" 0"
  ATTRS{bNumEndpoints}=="06"
  ATTRS{bInterfaceClass}=="ff"
  ATTRS{bInterfaceSubClass}=="00"
  ATTRS{bInterfaceProtocol}=="00"
  ATTRS{modalias}=="usb:v0CF3p7015d0202dcFFdscFFdpFFicFFisc00ip00"
  ATTRS{supports_autosuspend}=="0"


O adaptador USB está recebendo este nome de "wlan0" porque, quando o sistema o detectou, o udev atribuiu a regra abaixo:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:3f:7c:2e:f4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"


Mas, com estas informações da saída do comando udevadm podemos mudar o nome do device para, por exemplo, Wireless0 como mostra a regra abaixo:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:3f:7c:2e:f4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="*", NAME="wireless0"


Explicando a regra:
  • 1º → É verificado se o dispositivo filho conectado é do tipo net (rede);
  • 2º → Verifica se o dispositivo acabou de se conectado;
  • 3º → Na chave de combinação DRIVERS informa que pode ser usado qualquer driver para o respectivo device parent;
  • 4º → Na chave de atributo ATTR{address} é verificado o endereço MAC address do device;
  • 5º e 6º → São verificados mais duas chaves de atributos da mesma (note que ambas foram atribuídas junto ao dispositivo filho, por isso a regra funciona);
  • 7º → Na chave KERNEL é verificado qual o nome atribuído pelo kernel, no exemplo informei que pode ser qualquer um;
  • 8º → Na última chave de combinação informei o novo nome do dispositivo que é wireless0.

Podemos fazer muitas personalizações, além das quais já foram mostradas, podemos, por exemplo, automatizar um processo de backup toda vez que o dispositivo for conectado à máquina de forma similar à regra acima, que executa um script.

Após aplicar uma regra em um dos arquivos com extensão ".rules", torna-se necessário reiniciar o serviço do udev para as alterações entrarem em vigor (pelo menos nas distribuições Debian e CentOS, por exemplo).

Referências

Página anterior    

Páginas do artigo
   1. Detecção e ativação de dispositivos e a função do udev nesse processo
   2. Hierarquia dos dispositivos e chaves do udev
   3. Regras do udev
Outros artigos deste autor

Open source fomentando o conhecimento

IDS com Debian 4, Snort 2.8.3.1 e BASE 1.4.1

Instalando o Ubuntu no pendrive

Zenwalk - Uma distro e tanto

Instalação e configuração do gdesklets no Slackware 10

Leitura recomendada

Fãs do pinguim, vamos à luta!

obshutdown, Shutdown Menu para OpenBox

DJVU o formato que pode ameaçar o reinado do PDF

5 coisas que todo aluno de Sistemas de Informação deveria saber (e fazer)...

Instalando um novo tema no Acer Aspire One

  
Comentários
[1] Comentário enviado por danniel-lara em 22/10/2012 - 20:41h

muito bom o artigo
parabéns

[2] Comentário enviado por removido em 23/10/2012 - 05:07h

cabra, tu és muito corajoso!!! merece 10....
;-))

[3] Comentário enviado por julio_hoffimann em 23/10/2012 - 18:32h

Parabéns Edson!

Abraço!

[4] Comentário enviado por removido em 23/10/2012 - 18:46h

Obrigado pelos comentários pessoal!!!

[5] Comentário enviado por removido em 23/10/2012 - 23:57h

Grande Edson!

Sempre aprendo muito com seus artigos.


Mesmo quase tudo no Linux ser arquivo, estava com dificuldades em entender a estrutura do UDEV.

Ótimo trabalho!

[6] Comentário enviado por antonio.gatto em 08/11/2012 - 12:46h

Muito Bom o Artigo !!

[7] Comentário enviado por rodcorporation em 11/01/2013 - 12:20h

Manooo! Já li muito artigo aqui, achei esse um dos melhores que ja li! Achei interessante. Parabéns, uma dica para o artigo, demorei pra perceber que os dispositivos pais terminam com S, por exemplo DRIVERS, KERNELS e SUBSYSTEMS, seria legal informar que os pais tem o S no final, principalmente a regra que você deu de exemplo onde a primeira não funciona, nao conseguia entender pq exatamente o DRIVERS se referia o pai. por causa do S.

Outra coisa que eu queria perguntar, o que é possível fazer com o udev com as regras?

Valeu man, nota 10!

[8] Comentário enviado por removido em 13/01/2013 - 15:52h

É possível executar scripts para fins diversos sempre que um dispositivo reconhecido e criado, nomear os respectivos nomes contidos para os mesmos em /dev.

[9] Comentário enviado por removido em 09/02/2013 - 07:23h

Olá. Parabéns pelo artigo.

Gostaria de saber se há mais documentação pro udev além dos txts da documentação do kernel.

Não havia encontrado além, até ler seu artigo.

"Site" do udev: https://www.kernel.org/pub/linux/utils/kernel/hotplug/

[10] Comentário enviado por removido em 09/02/2013 - 09:30h

Obrigado pelo comentário Listeiro_037 !

Na ultima página do artigo deixei algumas referências usadas para conclusão do trabalho. E no wiki do archlinux também tem algumas documentações.

[11] Comentário enviado por MAPOGOS em 01/07/2013 - 20:11h

Porque remover os nós dos dispositivo?
E quando necessariamente deverei fazer este cmd?
Obrigado;
Estudante.

[12] Comentário enviado por Renan20 em 29/07/2013 - 00:08h

Muito bom o seu artigo (parabéns)

[13] Comentário enviado por Zephyr em 29/01/2015 - 01:03h

Parabéns pelo artigo: ficou bem claro e explicativo.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts