MKB phpBB

Источник: http://illumium.org/node/103

Не очень коротко про udev

Есть такая замудрёная штука в этих наших linux-ах, как udev. Это сервис, который подхватывает и конфигурирует периферию, получая уведомления от ядра. Он гибко настраивается под оборудование и задачи с помощью специальных правил. Стандартные системные правила обычно лежат в директории /lib/udev/rules.d, а наших инвалидов мы можем смело сохранять в /etc/udev/rules.d.

Правила очень простые и работают обычно влоб без всяких выкрутасов, однако, написать их с первого раза без хорошего понимания принципов устройства sysfs ядра linux бывает весьма не просто. В этом то мы сейчас и будем разбираться. Конечно, документации и примеров превеликое множество, но они, как правило, касаются стандартных вещей и тривиальных задач. Мы же будем делать несколько выходящее за рамки и с пониманием того, откуда что на самом деле берётся.

sysfs
Про sysfs (да-да ту самую, которая обычно монтируется в /sys), можно рассказать на большую статью, но здесь мы коснёмся только того, что нам чаще всего может понадобиться. Итак, вот некоторые важные для нас подкаталоги:

/bus — здесь расположены устройства по шинам обмена данными (неожиданно не правда ли ^_^ ). Как правило, сюда смотреть нам не понадобится, но будем иметь ввиду.
/class — тут устройства по классам. Это нам однозначно пригодится.
/devices — устройства по типам. Часто ядро бросает уведомления с путями устройств здесь, а из других подкаталогов сюда смотрят символьные ссылки.
/kernel/debug — файловая система отладочного интерфейса ядра. Может пригодится, чтобы смотерть, что не так с устройствами.
Будем иметь ввиду, что поскольку udev работает с sysfs, то все пути (syspath) следует рассматривать относительно /sys, то есть вместо /sys/devices/xyz писать /devices/xyz.

udevadm
Полезный инструмент для работы с udev, наверно, единственное, без чего нельзя обойтись при настройке.

Исследуем sysfs командой info
Вот как мы можем узнать, что udev думает об интересующем нас устройстве или подсистеме, для примера возьмём gpio на Raspberry Pi:
kayo@amaya ~ $ udevadm info --query=all --path=/class/gpio --attribute-walk В этом примере мы не получили ничего интересного, но сможем сделать вывод, что это территория ядра. Записи вида ABCD=="abcd" это селекторы, которые могут быть использованы в качестве условий в правилах.
Пойдём дальше, исследуем контроллер gpio:
kayo@amaya ~ $ udevadm info --query=all --path=/class/gpio/gpiochip0 --attribute-walk Уже интереснее, подсистема gpio и появились атрибуты: начальный порт: 0, количество портов: 54, метка указывает на драйвер контроллера: bcm2708_gpio. Кстати путь изменился потому, что на самом деле /sys/class/gpio/gpiochip0 это символьная ссылка, заруленая на /sys/devices/virtual/gpio/gpiochip0, в чём не сложно убедиться.

Давайте посмотрим что-нибудь другое, например устройство i2c:
kayo@amaya ~ $ udevadm info --query=all --path=/class/i2c-dev/i2c-1 --attribute-walk То, что мы здесь видим представляет собой иерархию вложенных друг в друга узлов от частного к общему. Выдавать такую ботву, как вы уже догадались, заставляет параметр --attribute-walk. Стоит обратить внимание на пути и на значения селекторов. У меня на этой шине сидят часы реального времени, поэтому можем сделать так:
kayo@amaya ~ $ udevadm info --query=all --path=/bus/i2c/devices/1-0068 --attribute-walk Поменялся только самый нижний (то есть верхний) узел, теперь там собственно сами часы.

Ловим события командой monitor
Часто бывает полезно мониторить события ядра и udev, чтобы понять, что происходит, например при добавлении или удалении интересующих нас устройств.
Мы можем запустить мониторинг так:
kayo@amaya ~ $ udevadm monitor --property --kernel --udev Здесь мы ловим все события ядра и самого udev со всеми свойствами. Конечно, можно указать фильтры, но обычно и так в выводе легко увидеть то, что нас интересует. Запускаем монитор, присоединяем устройство и смотрим, что мы имеем.
Давайте для примера попробуем проинициализировать порт gpio:
kayo@amaya ~ $ echo 30 | sudo tee /sys/class/gpio/export >/dev/null
При этом в мониторе будет примерно следующее: Пришло два события добавления устройства: одно от ядра, другое сгенерировал сам udev.
Теперь можно исследовать появившееся устройство как мы это уже делали:
kayo@amaya ~ $ udevadm info --query=all --path=/class/gpio/gpio30 --attribute-walk Как видим, всё так, как и ожидается.
А теперь удалим порт:
kayo@amaya ~ $ echo 30 | sudo tee /sys/class/gpio/unexport >/dev/null
Будет всё тоже самое, только действие удаление вместо добавления: Пробуем писать правила
Итак, откуда что берётся мы более-менее разобрались, настало время написать какие-нибудь полезные правила.

Допустим, нам нужно предоставить доступ к устройствам gpio группе gpio. Создаём файл /etc/udev/rules.d/90-gpio.rules, цифра по традиции это приоритет правила. Для управления gpio, то есть активации/деактивации портов служат файлы /sys/class/gpio/export и /sys/class/gpio/unexport. Для управления направлением работы порта и получения/установки значения используются файлы /sys/class/gpio/gpioN/direction и /sys/class/gpio/gpioN/value соответственно. Всё, что нам нужно, переназначить группу для всех этих файлов в gpio, а затем дать права на запись в них для группы.
Вот мой вариант правил: Первое правило настраивает доступ к интерфейсам export/unexport, а второе — к direction и value каждого настроенного порта. Как было сказано выше, записи ABCD=="xyz" — это селекторы, задающие условие срабатывания правила. Правило действует, если все условия соблюдены. Записи ABCD="xyz" — это действия, то есть то, что будет выполнено при активации правила. В селекторах можно использовать простые шаблоны:

«*» — любое количество символов, в том числе и не одного
«?» — один или ниодного символа
«[abcd]» — один из символов группы (можно задавать диапазоны вида [a-z], [0-9] и тд)
Слишком многого от шаблонов ожидать не следует, это вам не регулярные выражения, однако функционала вполне достаточно для всего. В наших правилах мы использовали шаблон [0-9]* для обобщения имени KERNEL номером устройства. Чтобы инвертировать действие селектора, надо писать его в виде ABCD!="xyz".

В действиях можно использовать подстановки вида %xyz. Вот некоторые из них:

%k — имя KERNEL устройства
%n — номер KERNEL устройства
%p — значение DEVPATH
В наших правилах мы использовали подстановку %p, чтобы не писать длинное значение DEVPATH. Мы использовали действие вызова внешней программы в котором запустили оболочку, чтобы выполнить назначение группы и предоставить права доступа. Здесь может возникнуть мысль, что запускать оболочку — действие избыточное и не обязательное, однако, udev не выполнит более одной программы, указать дважды PROGRAM в одном правиле нельзя, потому что последнее присвоение заменит первое. Более хорошей идеей может быть написать правило дважды, но я не уверен, так ли это на самом деле.

Раньше, когда я исследовал внутренности sysfs, мне казалось странным огромное количество символьных ссылок в разных каталогах, которые порой заставляют следовать длинными зацикленными цепочками. Вся их полезность становится очевидна когда начинаешь писать правила udev. В нашем случае мы использовали символьную ссылку subsystem, чтобы прийти к интерфейсам управления портами, хоть в данном случае пример не очень показателен.

Тестируем правила
Чтобы понять, не накосячили ли мы случайно где-нибудь, можем сделать следующее:
kayo@amaya ~ $ udevadm test --action=add /class/gpio/gpiochip0 Здесь мы форсируем событие, а udev читает правила и выполняет действия при совпадении условий. Я выполнил это под непривилегированным пользователем, поэтому получил ненулевой код возврата.

Чтобы добавленные правила начали работать, надо заставить демон их перечитать:
kayo@amaya ~ $ sudo udevadm control --reload
Теперь добавляем устройства, как мы это уже делали и смотрим, установились ли привилегии.

Давайте напишем ещё каких-нибудь правил. Как я говорил, у нас есть часы реального времени на шине i2c, однако, система не в состоянии правильно связать устройство часов с шиной без дополнительных правил. Логично использовать для этих целей событие добавления устройства i2c, возникающее при инициализации драйвера: Правило для удаления здесь приведено до кучи, я не уверен, что оно необходимо, поскольку когда драйвер i2c выгружается, связанные устройства автоматически удаляются.

Типа заключение
Как видим, всё не так уж и страшно, а напротив, просто и логично. Так что пора заканчивать разводить бардак в /etc/rc.local и писать udev правила для всей этой ядерной кухни.