Udev linux что это
Еще раз про udev
Автор: Алексей Федорчук
Несколько лет назад, почти сразу после внедрения в Linux механизма udev, я написал краткую заметку по поводу с первых разборок с оным. Нынче, в связи со вновь образовавшимися обстоятельствами, настало время опять обратиться к этой теме, расширив и даже, как сказал бы один из наших президентов, углубив её.
Прежде чем начать настоящую заметку, оговорюсь, что в неё включён весь материал заметки прежней — тот, что сохранил актуальность. Так что обращаться к последней необходимости нет — разве что в историческом аспекте.
Udev — это механизм поддержки настраиваемогодинамического именования устройств в Linux, пришедшая на смену виртуальной файловой системе устройств devfs; во FreeBSD эта функция возлагается на последнюю. Первый и основной разработчик udev — Грег Кроа-Хартман (Greg Kroah-Hartman).
В отличие от devfs, udev — не файловая система, поддерживаемая ядром, а обычная пользовательская программа. Для своего функционирования udev нуждается в виртуальной файловой системе — sysfs. Основываясь на информации из неё, udev и присваивает имена различным устройствам, в том числе и при горячем их подключении.
Как известно, любой POSIX-системе имена конкретных устройств более или менее безразличны, так как оперирует она не с ними, а с их идентификаторами. Ранее, до внедрения devfs и, позднее, udev), в качестве таковых выступали так называемые номера устройств — старший номер устройства, определяющий его класс (например, ide-накопители) и младший его номер, указывающий на конкретный экземпляр данного представителя класса. Ныне же используются непосредственные идентификаторы устройств — серийный номер винчестера, его положение на SATA-разъёме или канале PATA-шины, и так далее. Сочетание их для каждого диска (раздела, и так далее) оказывается уникальным. Так вот, udev извлекает эти сведения из файловой системы sysfs и, руководствуясь определенными правилами,
ставит им в соответствие “человеческие” имена (вроде тех же /dev/sda и так далее).
Процесс включения поддержки udev очень прост и сводится к установке пакета udev — во всех современных дистрибутивах Linux он входит в базовую систему, так что специально его устанавливать не нужно.
Далее, следует позаботиться о запуске демона udevd при старте системы. За это отвечает один из сценариев инициализации, зависящий от дистрибутива. Например, в Ubuntu это будет файл /etc/init.d/udev. Впрочем, в любом современном дистрибутиве это также происходит по умолчанию, так что руками ничего править не надо.
Теперь в каталоге /dev можно видеть привычные имена файлов устройств — /dev/sda, соответствующее винчестеру на первом разъёме SATA, /dev/sda3 для его разделов, а также /dev/sr0 для CD-привода; имеется и традиционный файл устройства /dev/cdrom — символическая ссылка на /dev/sr0:
Подключение флэш-накопителя в USB-разъем немедленно приводит к появлению в списке устройства с именем /dev/sdb, не меняющееся, сколько бы ни повторять эту процедуру.
Иными словами, каталог /dev приобретает вид, привычный по временам статического именования устройств. С той только разницей, что теперь он не заполнен впрок файлами возможных, но не существующих устройств.
За конфигурирование механизма udev отвечает специальный файл —
/etc/udev/udev.conf, определяющий глобальные параметры, корневой каталог для файлов устройств (по умолчанию — /dev), файл базы данных устройств, файлы описания правил именования устройств и прав доступа к ним, а также правила создания символических ссылок (подобных /dev/cdrom). Конкретные имена этих файлов и их местоположение зависят от дистрибутива. Обычно это файлы вида /etc/udev/rules.d/udev.rules и
/etc/udev/permissions.d/udev.permissions.
Ручное вмешательство в конфигурационные файлы требуется редко, но иногда такая
необходимость возникает. Так, на заре внедрения механизма udev я столкнулся (в
дистрибутиве Archlinux) с такой ситуацией: после перезапуска машины с задействованным udev у меня исчез звук — и с первого же взгляда на файл /etc/udev/permissions.d/udev.permissions стало ясно, почему. Права доступа ко всем аудио-устройствам имели примерно такой вид:
где dsp — имя устройства, root:root — хозяин и группа, соответственно, 0660 — маска,
определяющая запрещение доступа для всех, кроме хозяин и группы. У меня же
ранее устройства, связанные с воспроизведением аудио, относились к
группе sound, в которую я и включал себя.
Так что пришлось срочно заменить второе вхождение root’а на группу sound — и
после перезапуска со звуком все стало нормально.
Для управления механизмом udev “на лету” служит утилита udevadm. В частности,
с её помощью можно определить уникальные идентификаторы любых устройств — в
современных дистрибутивах, как уже было сказано, именно они используются,
например, для автоматического монтирования файловых систем при старте машины. Для этой цели следует дать команду udevadm примерно в таком виде:
Здесь субкоманда info предписывает вывести информацию, опция –query определяет, какую именно (env — спецификации устройства), а значением опции –name будет имя файла устройства. Среди множества параметров, таких, как модель диска, его интерфейс
и многое другое, будет и искомый идентификатор устройства примерно такого облика (именно его мы отфильтровываем, передавая вывод утилиты udevadm команде
grep):
Этот идентификатор можно использовать в файле /etc/fstab вместо имени устройства,
примерно таким образом:
Что имеет и свои недостатки, и свои достоинства. Недостатки — очевидны:
громоздкость и неудобочитаемость файла.
Достоинства не лежат на поверхности, но также имеют место быть: в частности, при переключении дисков с одного SATA-разъема на другой, или при смене последовательности обращения к винчестерам в BIOS Setup, не нужно думать об
изменении соответствующих строк в /etc/fstab.
Ещё одна напрашивающаяся сфера применения UUID — обеспечение безопасности.
Так, внесением в /etc/fstab строк вида
можно разрешить монтировать от лица обычного пользователя, скажем, не
флэш-накопители вообще, а только совершенно конкретные флэшки. То же
самое можно распространить на CD- и DVD-носители, камеры etc. Способ довольно
хлопотный — потребуется вносить много строк в /etc/fstab и отключать автомонтирование
сменных накопителей через HAL (о котором речь пойдёт в следующем разделе). Однако
можно представить себе ситуации, когда он будет оправдан.
Одна из дополнительных особенностей udev — возможность создавать файлы
устройств с нестандартными именами, например, /dev/camera — для цифрового
фотоаппарата, /dev/flash — для флэш-накопителя, и так далее. Это полезно, в частности,
если одновременно подключено несколько устройств с интерфейсом одного типа —
скажем, та же камера и флэшка, поскольку не нужно задать, какое из имен файлов
устройств вида /dev/sd?# чему соответствует.
Рассмотрим этот вопрос на примере обычного флэш-накопителя с USB-интерфейсом.
Для чего подключаем интересующее нас устройство и в с помощью всё той же
команды udevadm определяем его идентификатор:
Теперь нам понадобятся права администратора для создания файла описания правил,
получаемый, например, так:
После ввода пользовательского пароля мы оказываемся в редакторе по умолчанию,
определяемом значением переменной EDITOR данного пользователя (у меня это nano); если таковая не определена, будет вызван стандартный vi. В открытый в нём пустой файл (имя его произвольно, важно только проследить, чтобы он считывался раньше стандартных для данного дистрибутива файлов описаний правил), вносим единственную строку
где значением переменной ID_FS_UUID будет полученный выше идентификатор устройства, значением переменной NAME — какое-либо мнемонически удобное имя, в данном случае символизирующее, что мы имеем дело с флэшкой объёмом 256 Мбайт.
Перезагрузки системы не потребуется: для проверки правильности выполненных действий достаточно отсоединить устройство и подключить его заново.
Конфигурационные файлы udev при этом будут перечитаны, в результате чего в
каталоге /dev/ появится файл с соответствующим именем:
Повторяем процедуру для всех интересующих нас устройств: так, я проделываю это для
постоянно используемых мной флэшек объемом 1 Гбайт и 16 Гбайт, определяя для них имена fl1g и fl16g, соответственно.
С камерой всё точно также, однако разнообразия ради проделаем описанную процедуру несколько иным путём, а именно: подключаем камеру и даём команду devadm в несколько иной форме:
После чего в файл /etc/udev/rules.d/00-flash.rules добавляем соответствующую строку:
И после отключения и повторного присоединения устройства имеем счастье наблюдать в каталоге /dev новый файл:
Ещё один способ придать файлам устройств имена, отличные от присваиваемых ядром
— использование символических ссылок. Это целесообразно, в частности, для
файлов устройств компакт- и DVD-приводов: ряд программ, например, Mplayer, при
проигрывании аудио-, видео-CD и DVD по умолчанию рассчитывает обнаружить их
в устройствах типа /dev/cdrom и /dev/dvd.
Поскольку файлы устройств создаются динамически при загрузке системы, то и
ссылки должны создаваться динамически, что также описывается соответствующими
правилами. В большинстве современных дистрибутивов Linux’а такие правила
задаются по умолчанию при инсталляции системы. Так, в Ubuntu они содержатся в
файле /etc/udev/rules.d/70-persistent-cd.rules в следующем виде:
1 комментарий к “ Еще раз про udev ”
Спасибо за статью, узнал много нового. О том, что устройства можно именовать произвольно я догадывался, но не знал, что сие настолько просто.
По поводу симлинка /dev/cdrom — у меня его почему-то нет. В файле /etc/udev/rules.d/70-persistent-cd.rules примерно следующее содержимое:
# _NEC_DVD_RW_ND-3550A (pci-0000:00:06.0-ide-0:0)
ENV
ENV
ENV
ENV
Судя по комментарию, DVD-привод вроде бы даже и сам определился, и сам подправил конфиг, как надо… Вот только почему-то не работает оно как надо.
Привод у меня /dev/hdc. Как узнать, какой адрес списывать вместо ENV?
Да, ещё по поводу камеры. Если я вставлю сразу две камеры с ID_MODEL=»Samsung_Digital_Camera», а такое, как я понимаю, вполне возможно, что будет?
Настройка udev rules в Linux
Правила udev помогут вам, если вы хотите:
Общая информация про udev
Правила udev хранятся в папке /etc/udev/rules.d. Файл правил обязательно должен иметь расширение .rules. Обычно в этой папке уже есть несколько файлов udev rules, но их трогать не рекомендуется, для своих правил лучше создать отдельный файл, например:
SUBSYSTEM==»block», ATTR(size)==»1343153213″, NAME=»mydisk»
Это правило выполниться только для устройства подсистемы block и с размером 1343153213 байт. Откуда брать эти значения, мы рассмотрим ниже, а пока разберёмся, что же значат те или иные ключи. Сначала ключи соответствия:
Для действий используются ключи:
Рассмотрим подробнее ключ ATTR. Он позволяет получить информацию об устройстве, доступную в sysfs. Например, ATTR
Как переименовать устройство в Linux
Теперь на основе полученной из udevadm информации можем составить udev rules для добавления альтернативного имени диска:
SUBSYSTEM==»block», ATTR
Или смены названия:
SUBSYSTEM==»block», ATTR
Получим устройство /dev/root, которое будет указывать на корневой раздел (sda1), то же самое можно сделать для привода оптических дисков:
Затем добавляем правило на основе модели:
SUBSYSTEM==»block», ATTRS
После перезагрузки появится файл устройства /dev/cdrom. Хотя, конечно, это можно сделать без udev, прописав в автозагрузку команду создания символической ссылки:
Как переименовать сетевую карту
И создаём правило, например на основе mac-адреса:
SUBSYSTEM==»net», ATTR
==»00:d8:61:16:a5:a5″, NAME=»eth0″Перезагружаем компьютер, и теперь устройство называется eth0.
Как запустить скрипт при подключении устройства
Например, мы хотим автоматически скопировать все данные с флешки при её подключении к компьютеру. Мы знаем, что флешка будет называться /dev/sdb, тогда можно создать правило udev такого вида:
При подключении флешки выполнится скрипт /usr/bin/my_script и сделает необходимые действия. Нужно заметить, что скрипт не должен выполняться слишком долго, так как udev остановится и будет ожидать завершения его работы.
Отладка правил
Если вы не уверены, правильно ли составлено правило, можно воспользоваться командой udevadm test для проверки. В единственном параметре нужно передать путь sysfs-устройства. Например, проверим наше правило для жёсткого диска:
udevadm test /sys/block/sda
Среди многочисленного вывода видим строчку:
creating link ‘/dev/root’ to ‘/dev/sda’
Значит всё работает, и настройка udev выполнена успешно. Если же в правиле допустить синтаксическую ошибку, например UBSYSTEM вместо SUBSYSTEM, udevadm test выдаст что-то подобное:
read rules file: /etc/udev/rules.d/10-local.rules
unknown key ‘UBSYSTEM’ in /etc/udev/rules.d/10-local.rules:2
invalid rule ‘/etc/udev/rules.d/10-local.rules:2’
Здесь мы видим саму причину ошибки, неверный ключ, а также файл и строку, в которой допущена ошибка.
Выводы
На этом всё. Теперь вы знаете, как создать правило udev и взять под полный контроль все ваши устройства. Если нужна более подробная информация по созданию и использованию правил udev, читайте официальную документацию по udev в man.
Файловая система udev («юдев») появилась в ядрах версии 2.6 заместо DevFS («дев фс»)
udev позволяет назначать постоянные имена для устройств. Например, можно создать правило для монтирования жесткого диска производителем которого является «iRiver» с кодом устройства «ABC», как устройство /dev/iriver. Постоянность в названии устройств гарантирует, что все скрипты, зависящие от присутствия в системе определённых устройств, будут работать правильно.
Обзор
Демон udevd запускается скриптом /etc/rcS.d/udev. Файл конфигурации находится в /etc/udev/udev.conf. Файл правил для более полной настройки демона udevd лежит в /etc/udev/rules.d. Файлы находящиеся в данной директории оканчивающиеся на «.rules» парсятся в алфавитном порядке. При изменении конфигурационного файла или файла правил, демон udevd следует перезапускать.
Множество файлов, находящихся в директории /etc/udev/rules.d, ссылаются на другие файлы. Можно предположить, что при редактировании файлов правил, текстовый редактор сделает работоспособные резервные копии, которые можно будет использовать при следующем запуске udevd. Поскольку имена ссылок могут отличаться от имён исходных файлов, они могут быть упорядочены без опасений.
udev был создан для реагирования на события типа «горячего подключения». Большая часть документации касается создания файлов устройств для новых физических устройств появившихся в системе. Однако udev не является узкоспециализированным. Он может запускать любую команду пользовательского режима в ответ на обнаружение нового устройства или любого другого события, полученного от ядра.
Правила
пример соответствия (match): BUS=="usb"
пример действия (action): NAME="mydev"
действия (action) вида key+=»value» добавляются к существующим. Например, SYMLINK+="foo" означает, что в дополнение к любым другим symlinks («симлинкс»), которые должны быть выполнены для данного события, также следует выполнить foo. («фуу»)
Множество правил
В этом пространстве имеется возможность создавать метки и с их помощью пропускать некоторое количество правил, в зависимости от условия. Это осуществляется с помощью действия («action») GOTO
Существуют средства для динамического создания правил. Пример смотрите z45_persistent-net-generator.rules
Чёрные списки
Постоянное имя устройства
В данном примере, мы дадим постоянное имя для 3G модема.
1. Подсоедините устройство. 2. Выполните следующую команду на соответствующем устройстве:
3. Создайте файл в /etc/udev/rules.d и назовите его z21_persistent-local.rules.
4. Перезапустите скрипты (или выполните перезагрузку ; )
UDEV: Как установить свои правила
Оригинал: Writing udev rules
Автор: Daniel Drake (dsd)
Версия 0.74
Свободный перевод: Алексей Дмитриев
Дата перевода: 19 августа 2008
Содержание:
Введение
Об этой статье
С течением лет область применения правил udev изменялась, так же как и гибкость самих правил. В современных системах, udev обеспечивает постоянное наименование для ряда типов устройств (элементов), что называется «из коробки», исключая тем самым установление правил для этих устройств (элементов). Однако некоторые пользователи по-прежнему требуют (желают) дополнительного уровня настройки.
В данной статье подразумевается, что udev у вас установлен, и нормально работает с настройками по умолчанию. Это обычно и происходит при установке дистрибутива Linux.
Статья не охватывает каждый нюанс установки правил, но претендует на описание всех основных концепций. Тонкие детали требуют изучения манов.
Для иллюстрации идей и концепций в статье приводится множество примеров (многие из которых полностью выдуманы). Поскольку не весь синтаксис подробно и недвусмысленно объясняется в сопровождающих текстах, для полного понимания лучше всего обратиться к примерам.
Общее представление, концепция
Термины: devfs, sysfs, nodes, etc
В типичной Linux системе, директория /dev используется для хранения элементов, называемых нодами. Они похожи на файлы и соответствуют определенным устройствам системы. Каждая нода указывает на часть системы (устройство), которое может существовать, а может и не существовать. Пользовательские приложения могут использовать ноды этих устройств для взаимодействия с системным «железом». Например, X server будет «прислушиваться» к /dev/input/mice, чтобы иметь возможность соотнести пользовательские движения мыши с видимыми на экране перемещениями курсора.
sysfs является новой файловой системой для ядер 2.6. Она управляется ядром и выдает основную информацию об устройствах, в данный момент времени подключенных к системе. udev использует эту информацию для создания нод устройств, соответствующих вашему аппаратному обеспечению. Файловая система sysfs монтируется в точку /sys и является просматриваемой. Можно исследовать файлы, находящиеся в этой директории, прежде чем начинать дело с udev. В данной статье я буду обращаться с терминами /sys и sysfs как с синонимами.
Зачем это нужно?
Установлением правил нельзя обойти проблему, когда для вашего конкретного устройства не существует ноды. Даже если нет никаких подходящих правил, udev все равно создаст ноду устройства с именем по умолчанию, обеспеченному ядром.
У постоянных имен нод устройств есть ряд преимуществ. Предположим, у вас есть два USB накопителя: цифровая камера и USB флешка. Эти два устройства являются типичными нодами устройств с назначаемыми именами: /dev/sda и /dev/sdb. Но конкретное назначение имени устройства зависит от порядка их подключения. Это может сбивать с толку пользователей, которые, несомненно, были бы рады, если бы каждое устройство каждый раз называлось одинаково, скажем, /dev/camera и /dev/flashdisk.
Встроенные постоянные схемы наименования
udev обеспечивает постоянное наименование «из коробки» для накопительных устройств в директории /dev/disk. Чтобы ознакомиться с постоянными именами, которые созданы для ваших накопителей, можно воспользоваться командой:
Когда я подключаю свой USB флеш диск, udev создает ноду-
/dev/disk/by-id/usb-Prolific_Technology_Inc._USB_Mass_Storage_Device-part1,
что также является постоянным именем.
Установление правил
Файлы правил и их семантика (смысл слов и символов)
Файлы в директории /etc/udev/rules.d/ расположены в алфавитном порядке; в некоторых обстоятельствах этот порядок может быть важен. Вы ведь хотите, чтобы ваши правила шли впереди правил по умолчанию, так я предлагаю создать файл в директории /etc/udev/rules.d/10-local.rules и вписывать все ваши правила в этот файл.
В файлах правил, строки, начинающиеся со знака «#», считаются комментариями. Любая другая непустая строка является правилом. Правило не может занимать несколько строк.
Одну устройству может соответствовать больше одного правила. Это имеет практические преимущества, например можно установить два правила, относящихся к одному и тому же устройству, и каждое правило будет обеспечивать устройству собственное альтернативное имя. Оба альтернативных имени будут созданы, даже если правила прописаны в разных файлах. Важно понять, что udev не остановится, найдя соответствующее устройству правило, но будет продолжать поиск и пытаться выполнить каждое правило, о котором знает.
Синтаксис правил
Вот пример правила для иллюстрации вышесказанного:
Это правило включает в себя один ключ соответствия (KERNEL) и один ключ назначения (NAME). Семантика и свойства этих ключей будут детализированы позже. Важно отметить, что ключ соответствия (match key) относится к своему значению через оператор равенства (==), тогда как ключ назначения (assignment key) относится к своему значению через оператор присвоения (=).
Помните, что udev не поддерживает переноса строк ни в какой форме. Не допускайте разрыва строк в ваших правилах, так как udev интерпретирует ваше одно правило как несколько правил, и не будет работать как ожидалось.
Базовые правила
Как уже отмечалось ранее, udev создает только одну настоящую ноду устройства для одного устройства. Если вы хотите обеспечить этой ноде устройства альтернативные имена, то пользуйтесь возможностями символических ссылок. При помощи ключа назначения (assignment key) SYMLINK, вы фактически создаете список символических ссылок, каждая из которых нацелена (явно указывает) на реальную ноду устройства. Для управления этими ссылками мы представляем новый оператор для присоединения к спискам: +=. Вы можете присоединить множественные симлинки к списку любого правила путем отделения каждого следующего пробелом.
Это правило означает: речь идет об устройстве, которое было поименовано ядром как hdb; отныне вместо того, чтобы называть это устройство hdb, называйте ноду этого устройства my_spare_disk. Нода устройства появится как /dev/my_spare_disk.
KERNEL==»hdb», DRIVER==»ide-disk», SYMLINK+=»sparedisk»
А это правило означает: речь идет об устройстве, которое было поименовано ядром как hdb, и где драйвером является ide-disk. Наименуйте ноду этого устройства по умолчанию, и создайте к нему символическую ссылку по имени sparedisk. Обратите внимание, что мы не указали имя ноды устройства, поэтому udev использовал имя по умолчанию. Для того чтобы сохранить стандартную компоновку директории /dev, ваши собственные правила не будут обычно затрагивать ключ назначения NAME, но будут создавать ключи SYMLINK и (или) производить другие назначения.
KERNEL==»hdc», SYMLINK+=»cdrom cdrom0″
Скорее всего, это правило вы будете устанавливать чаще других. Оно создает две символические ссылки: на устройство /dev/cdrom, и устройство /dev/cdrom0, которые оба указывают на /dev/hdc. Опять-таки, ключ назначения NAME не был использован, так что ядро, по умолчанию, применило имя hdc.
Приведение в соответствие атрибутам sysfs
Многие драйверы экспортируют подобную информацию в sysfs, и udev позволяет нам включать sysfs-соответствия в наши правила. Это делается при помощи ключа ATTR, имеющего слегка отличающийся синтаксис.
Вот пример правила, устанавливающего единственное соответствие из sysfs. Позже в этой статье мы подробно опишем детали, помогающие вам составлять правила, основанные на атрибутах sysfs.
SUBSYSTEM==»block», ATTR
Иерархия устройств
Четыре основные ключа соответствия, представленные до сих пор (KERNEL/SUBSYSTEM/DRIVER/ATTR), соответствуют только значениям самих устройств, и не устанавливают соответствия со значениями родительских устройств. Но этот случай udev имеет варианты ключей соответствия, которые осуществляют поиск вверх по дереву устройств:
Постоянно имея в виду рассуждения об иерархии устройств, установление правил становится довольно сложным делом. Хорошо, что есть инструменты, способные помочь в этом деле: мы представим их немного позже.
Подстановка, или замена строк
Наиболее часты операторы %k и %n. %k вычисляет имя, присваиваемое ядром устройству, например «sda3» для устройства, которое по умолчанию появится как /dev/sda3. %n вычисляет номер, присваиваемый ядром устройству (номер раздела для накопителя), например, «3» для устройства /dev/sda3.
Для иллюстрации концепции подстановки строк вот несколько примеров правил:
KERNEL==»loop0″, NAME=»loop/%n», SYMLINK+=»%k»
Применение вышеприведенных правил под вопросом, так как их можно было составить без применения операторов подстановки. Полная сила операторов подстановки станет ясной из следующего раздела.
Подстановка по шаблонам
Вот несколько примеров, включающих перечисленные шаблоны. Обратите внимание на операторы подстановки строк.
KERNEL==»fd9*», NAME=»floppy/%n», SYMLINK+=»%k»
Это правило устанавливает соответствие со всеми флоппи дисководами, обеспечивает размещение нод устройств в директории /dev/floppy, а также создает символическую ссылку на имя по умолчанию.
Второе правило обеспечивает присутствие устройств hiddev только в директории /dev/usb.
Получение информации из sysfs
Дерево sysfs
sysfs имеет весьма простую структуру. Она логически поделена на директории. Каждая директория содержит определенное число файлов (характеристик), которые, как правило, имеют одно значение. Некоторое количество символических ссылок связывают устройства с их родителями. Иерархическая структура была описана выше.
К некоторым директориям обращаются как к путям устройств (paths) высшего уровня. Такие директории представляют реальные устройства, имеющие соответствующие ноды устройств. Пути устройств высшего уровня, могут быть классифицированы как директории sysfs, содержащие dev файл; их список можно просмотреть при помощи следующей команды:
Для примера, на моей системе, директория /sys/block/sda является путем устройства моего жесткого диска. При помощи символической ссылки /sys/block/sda/device он слинкован со своим родителем, устройством SCSI диск.
Когда вы устанавливаете правила на основе информации от sysfs, вы просто вставляете значение характеристики некоего файла в одну часть цепочки. Например, я могу узнать размер моего жесткого диска вот так:
# cat /sys/block/sda/size
234441648
При составлении правила udev, я могу использовать ATTR
Хотя это и полезное введение в структуру sysfs, и в механизм подбора значений udev, однако «прочесывание» sysfs вручную занимает много времени и вовсе необязательно.
udevinfo
Как легко видеть, udevinfo просто выдает список атрибутов (характеристик), которые вы можете использовать в качестве готовых ключей соответствия в ваших правилах udev. Используя вышеприведенный пример, я могу установить любое из двух следующих правил для одного устройства:
Вы обычно имеете на выбор множество атрибутов, и должны выбрать из них несколько, чтобы составить правило. Как правило, вам стоит выбирать те атрибуты, которые идентифицируют ваше устройство на постоянной основе и имеют вид, понятный для человека. В вышеприведенных примерах, я выбирал размер диска и номер его модели. Я не использовал бессмысленные (для человека) номера, такие как ATTRS
Рассмотрите эффекты иерархии в выводе команды udevinfo. Зеленая секция, соответствующая запрошенному устройству использует стандартные ключи соответствия, такие как KERNEL и ATTR. Синяя и коричневая секции соответствуют родительским устройствам, и используют отслеженные у родителей варианты вроде SUBSYSTEMS и ATTRS. Вот почему кажущаяся сложность иерархической структуры на поверку проста для использования, нужно только уверенно брать конкретные значения из числа предложенных командой udevinfo.
Также следует отметить, что обычно текстовые атрибуты появляются в выводе команды udevinfo с лишними пробелами (см. например ST3120827AS выше). При составлении ваших правил, можете либо сохранять лишние пробелы, либо убирать их, как сделал я.
Единственная сложность при работе с udevinfo состоит в необходимости точно знать полные пути устройств (paths) (в приведенном примере это /sys/block/sda). А эти пути не всегда очевидны. Однако, учитывая тот факт, что вы обычно устанавливаете правила для нод устройств, которые уже существуют, вы можете «попросить» udevinfo найти пути устройства для вас:
Альтернативные методы
Более сложные правила
Установка прав доступа и прав собственности
Ключ назначения GROUP позволяет установить, какая Юникс группа будет владеть нодой устройства. Вот пример правила, устанавливающего, что группа video владеет устройствами framebuffer’а:
KERNEL==»fb8*», NAME=»fb/%n», SYMLINK+=»%k», GROUP=»video»
Ключ назначения OWNER, возможно малоупотребительный, позволяет вам назначить владельца Юникс для ноды устройства. Не вдаваясь в довольно странную ситуацию, когда вы предаете право собственности на ваши флоппи устройства некоему john’у, вы можете составить такое правило:
По умолчанию, udev создает ноды устройств с Юникс правами доступа 0660 (чтение/запись для владельца и группы). Если потребуется, вы можете изменить настройки по умолчанию для определенных устройств, используя в правилах ключ назначения MODE. Следующее правило устанавливает, что нода inotify будет доступна на чтение и запись для всех:
KERNEL==»inotify», NAME=»misc/%k», SYMLINK+=»%k», MODE=»0666″
Использование сторонних программ для наименования устройств
Для этого вы просто указываете абсолютный путь (path) к этой программе (и любые параметры) в ключе назначения PROGRAM, а затем применяете один из вариантов оператора подстановки строк %c в ключах NAME/SYMLINK.
В нашем первом примере, мы подразумеваем, что device_namer выдает несколько частей, каждая из которых служит для создания символической ссылки (альтернативным именем) для нашего устройства.
KERNEL==»hda», PROGRAM=»/bin/device_namer %k», SYMLINK+=»%c»
KERNEL==»hda», PROGRAM=»/bin/device_namer %k», NAME=»%c<1>«, SYMLINK+=»%c<2>«
KERNEL==»hda», PROGRAM=»/bin/device_namer %k», NAME=»%c<1>«, SYMLINK+=»%c<2+>«
Части вывода могут использоваться в любых ключах назначения, а не только NAME и SYMLINK. Следующий пример использует фиктивную программу для назначения Юникс группы, которая будет владеть устройством:
KERNEL==»hda», PROGRAM=»/bin/who_owns_device %k», GROUP=»%c»
Запуск сторонних программ по определенным событиям
Не смешивайте этот случай с действием ключа PROGRAM, описанным выше. PROGRAM применяется для запуска программ, производящих имена устройств (и они не должны делать ничего, кроме этого). Во время запуска этих программ, нода устройства еще не создана, то есть никакое действие с устройством еще не возможно.
Действие, описанное в этой главе, позволяет вам запускать программу, когда нода устройства уже находится на своем месте. Эта программа может воздействовать на устройство, однако программа не должна работать продолжительное время, потому что udev эффективно останавливается во время работы таких программ. Способом обойти это ограничение является немедленное самоотключение программы.
Вот пример правила, демонстрирующий применение ключа назначения RUN:
udev не запускает такие программы на любом активном терминале, и не запускает их в контексте оболочки (shell). Убедитесь, что ваша программа является выполняемой (executable); если это скрипт шелла, убедитесь, что он стартует с соответствующим shebang http://en.wikipedia.org/wiki/Shebang_(Unix) (например, #!/bin/sh), и не ожидайте появления на вашем терминале стандартного вывода.
Взаимодействие среды окружения
В случае присоединения, вы можете создать переменные окружения, которые вы будете приводить в соответствие позже.
Вы можете также задать переменные окружения, которые будут использованы сторонними программами по технологиям, описанным ранее. Выдуманное правило установки переменных окружения показано ниже:
KERNEL==»fd0″, SYMLINK+=»floppy», ENV
В плане соответствия, вы можете сделать так, что правило будет действовать только в зависимости от значения переменной окружения. Имейте в виду, что окружение, каким его видит udev, вовсе не совпадает с окружением, которое видит пользователь в консоли. Вымышленный пример правила, показывающий приведение в соответствие при помощи переменной окружения, перед вами:
Дополнительные опции
Примеры
USB принтер
И я составляю вот такое правило:
SUBSYSTEM==»usb», ATTRS
USB камера
KERNEL==»sd?1″, SUBSYSTEMS==»scsi», ATTRS
Жесткий USB диск
Конечно, если у вас 100Гб USB винчестер, вполне понятно желание разбить его на разделы. В этом случае, мы используем преимущества подстановки строк:
KERNEL==»sd*», SUBSYSTEMS==»scsi», ATTRS
Это правило создает симлинки:
USB Card Reader (читатель флеш карт)
Обычно эти устройства не информируют компьютер, к которому подключены, о замене носителя (карты). Так что, если вы подключите кардридер без карты, а потом вставите карту, компьютер этого «не поймет» и у вас не будет монтируемой ноды sdb1 для носителя.
Одно из возможных решений: воспользоваться преимуществом опции all_partitions, которая создаст 16 нод разделов для каждого блочного устройства, о котором говорится в правиле:
KERNEL=»sd*», SUBSYSTEMS==»scsi», ATTRS
USB Palm Pilot (наладонник)
Carsten Clasohm’s blog post http://www.clasohm.com/blog/one-entry?entry%5fid=12096 является прекрасным источником для этого дела. Правило Carsten’а приведено ниже:
SUBSYSTEMS==»usb», ATTRS
Заметьте, что атрибут с названием продукта будет другим для других моделей, так что проверьте (при помощи udevinfo), какой именно соответствует вашему.
CD/DVD дисководы
Так как мы знаем имена, присвоенные ядром этим устройствам, составление правил просто. Вот несколько примеров для моей системы:
SUBSYSTEM==»block», KERNEL==»hdc», SYMLINK+=»dvd», GROUP=»cdrom»
SUBSYSTEM==»block», KERNEL==»hdd», SYMLINK+=»dvdrw», GROUP=»cdrom»
Сетевые интерфейсы
Имеет смысл просто указать MAC адрес вашего интерфейса в правиле, так как он уникален. Тем не менее, убедитесь, что используете тот самый MAC адрес, что и в udevinfo, потому что, если вы не приведете адрес точно, то правило работать не будет.
KERNEL==»eth*», ATTR
==»00:52:8b:d5:04:48″, NAME=»lan»Вам придется перезагрузить сетевой драйвер, чтобы это правило заработало. Можете либо выгрузить, и снова загрузить модуль, либо просто перезагрузить систему. Также придется перенастроить систему на использование «lan» вместо «eth0». Я имел определенные трудности, добиваясь этого (интерфейс не был переименован), пока я совершенно не отказался от ссылок на eth0. После этого, вы сможете использовать «lan» вместо «eth0» во всех вызовах к ifconfig и прочим утилитам.
Тестирование и отладка
Как заставить правила работать
Несмотря на это, udev не станет автоматически переделывать все устройства и пытаться применить новые правила. Например, если вы составили правило, добавляющее еще одну символическую ссылку для вашей камеры, в то время, когда камера была подключена, вы не можете рассчитывать на появление новой символической ссылки прямо сейчас.
Чтобы ссылка появилась, вы можете либо отключить и снова подключить камеру, либо (в случае неотключаемого устройства) можете запустить программу udevtrigger.
Если же ваше ядро не поддерживает inotify, то новые правила не будут обнаружены автоматически. В этой ситуации следует запускать программу udevcontrol reload_rules после каждого изменения файла правил, чтобы эти изменения возымели эффект.
udevtest
Имейте в виду, что /sys prefix был удален из числа аргументов командной строки udevtest, потому что udevtest оперирует с путями (path) устройства. Также заметьте, что udevtest является чисто тестовым и отладочным инструментом, он не создает ноды устройств, невзирая на предложения вывода этой программы!
Об авторе и контактах
Для поддержки подпишитесь на linux-hotplug mailing list: linux-hotplug-devel@lists.sourceforge.net
Copyright (C) 2003-2006 Daniel Drake. This document is licensed under the GNU General Public License, Version 2.