Comportamento de regras do udev estranho

1

Estou tentando entender como as regras do udev são interpretadas. Contexto: tornar um scanner USB acessível a mim mesmo como usuário não raiz (faço parte do grupo scanner ).

A seguinte regra não funciona :

SUBSYSTEM=="usb_device", ACTION=="add", ATTR{idVendor}=="04a9", ATTR{idProduct}=="190d", SYMLINK+="scan-canon", MODE="0666", OWNER="misha", GROUP="scanner"

No entanto, a seguinte regra funciona:

SUBSYSTEM!="usb_device", ACTION!="add", GOTO="canon_rules_end"

ATTR{idVendor}=="04a9", ATTR{idProduct}=="190d", SYMLINK+="scan-canon", MODE="0666", OWNER="misha", GROUP="scanner"

LABEL="canon_rules_end"

Certamente as duas versões são logicamente equivalentes? Eu simplesmente não consigo entender por que a primeira versão mais elegante não funciona. Alguma idéia?

    
por misha256 12.09.2015 / 11:30

1 resposta

0

Depois de arrancar tanto cabelo, descobri.

Acontece que o SUBSYSTEM do meu scanner é, na verdade, usb . É por isso que a primeira versão da regra (a elegante) falha - como deveria, porque SUBSYSTEM não é igual a usb_device .

A segunda versão funciona, mas por todos os motivos errados. As pessoas que fazem codificação estarão familiarizadas com esse tipo insidioso de bug auto-infligido. O Udev aplica a lógica AND às condições especificadas. Isso significa que, se qualquer das condições for avaliado como Falso, o GOTO não será executado e a carne da regra será executada. Misturar condições negadas com a lógica AND é apenas desagradável.

De qualquer forma, agora que consertei a primeira versão, ela funciona exatamente como esperado:

SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="04a9", ATTR{idProduct}=="190d", SYMLINK+="scan-canon", MODE="0666", OWNER="misha", GROUP="scanner"

EDIT: Como ikrabbe aponta, as duas versões originais nunca foram logicamente equivalentes.

    
por 12.09.2015 / 13:32

Tags