В Глава 8, мы установили пакет udev во время сборки eudev . Прежде чем мы углубимся в детали того, как это работает, необходимо кратко рассказать о предыдущих методах взаимодействия с устройствами.
Системы Linux традиционно использовали метод статического создания
устройств, при котором огромное количество узлов устройств(иногда
буквально тысячи узлов) создавалось в /dev, независимо от того, существовали ли
соответствующие аппаратные устройства на самом деле. Обычно это
делалось с помощью скрипта MAKEDEV, который содержал команды
вызова программы mknod
с нужным количеством устройств для всех возможных вариантов, которые
только могут существовать в мире.
Используя метод udev, только те устройства, которые были обнаружены
ядром, получают свой узел. Поскольку эти узлы будут создаваться
каждый раз, при загрузке системы, они будут располагаться в каталоге
файловой системы devtmpfs
(виртуальная файловая система, которая полностью находится в
оперативной памяти). Узлы не занимают много места в памяти и их общий
размер незначителен.
В феврале 2000 года, новая файловая система devfs была принята в ветку ядра 2.3.46 и была
доступна на протяжении выпуска стабильных релизов ветки 2.4. Хотя
она и присутствовала в ядре, такой способ динамического создания
устройств никогда не получал поддержки от разработчиков ядра.
Основная проблема с подходом, принятым devfs была связана с обработкой обнаружения,
создания и назначения имен устройствам. Проблема связанная с
именованием узлов была самой важной. Как правило, если имена
устройствам можно настраивать, то политика назначения имён должна
быть установлена системным администратором, а не навязываться
каким-либо разработчиком. Файловая система devfs также страдала от состояния гонки,
которое было присуще ее дизайну и не могло быть исправлено без
существенной переработки самого ядра. В конечном счёте, эта
файловая система была помечена как устаревшая на протяжении
достаточно долгого периода времени, по причине отсутствия её
ненадлежащей поддержки, и была удалена из ветки ядра в июне 2006
года.
При разработке нестабильной ветки ядра 2.5, позднее, выпущенной как
стабильный релиз 2.6, появилась новая виртуальная файловая система
sysfs. Задача этой файловой системы
заключалась в экспорте представления об аппаратной конфигурации
системы в процессы пользовательского пространства. С помощью этого
представления, видимого в пользовательском пространстве, разработка
замены для devfs стала гораздо
реалистичнее.
Краткое описание файловой системы sysfs было представлено выше. Можно задаться
вопросом, как sysfs получает
информацию об устройствах в системе, и о том, какие номера
устройств должны использоваться для них. Драйверы,
скомпилированные в ядро, напрямую регистрируют объекты с помощью
sysfs (внутри devtmpfs), по мере обнаружения ядром. Для
драйверов, которые скомпилированы в виде модулей, регистрация
будет происходить при его загрузке. После того, как файловая
система sysfs будет
примонтирована в каталог /sys,
данные, которые регистрируются драйверами, в sysfs, станут доступны для пользовательского
окружения и udevd для обработки (включая изменения узлов
устройств).
Файлы устройств создаются ядром при помощи файловой системы
devtmpfs. Любой драйвер, которому
необходимо зарегистрировать узел устройства, будет проходить
через файловую систему devtmpfs
(через системный драйвер ядра). Когда экземпляр devtmpfs монтируется в каталог /dev, узел устройства будет создан с
фиксированным именем, соответствующими разрешениями и владельцем.
Через некоторое время, ядро отправит uevent в udevd. На основе правил,
которые указанны в файлах в каталогах /etc/udev/rules.d, /lib/udev/rules.d, и /run/udev/rules.d, udevd создаст дополнительные
символические ссылки на узлы устройств, или сменит разрешения,
владельца или группу, или изменит запись (имя) во внутренней базе
данных udevd для
этого объекта.
Правила в этих трёх каталогах пронумерованы и используются
совместно. Если udevd не может найти правило
для устройства, он оставит права доступа и владельца на
devtmpfs, которые были
установлены изначально.
Драйверы устройств, скомпилированные в виде модулей ядра могут
содержать встроенные псевдонимы. Псевдонимы можно увидеть
просмотрев вывод программы modinfo, обычно они связаны со
специфичными для шины идентификаторами устройств, которые
поддерживается модулем. Например, драйвер snd-fm801 подерживает PCI устройства с
идентификатором поставщика 0x1319 и идентификатором устройства
0x0801, и имеет псевдоним «pci:v00001319d00000801sv*sd*bc04sc01i*».
Для большинства устройств, драйвер шины экспортирует псевдонимы
драйвера, которые будет обрабатывать устройство через
sysfs. Например, файл
/sys/bus/pci/devices/0000:00:0d.0/modalias
может содержать строку «pci:v00001319d00000801sv00001319sd00001319bc04sc01i00».
Правила по умолчанию, которые предоставлены Udev, заставят
udevd вызвать
/sbin/modprobe с
содержимым, которое находится в значении переменной окружения
MODALIAS uevent (которое должно
совпадать с содержимым файла modalias в sysfs), тем самым загружая все
модули, чьи псевдонимы совпадают в строке после расширение
подстановочных знаков
В указанном примере, это означает, что в дополнение к snd-fm801 будет загружен устаревший (и нежелательный) драйвер forte, если он будет доступен. Ниже приведены способы, как можно предотвратить загрузку нежелательных драйверов.
Само ядро также способно загружать модули для сетевых протоколов, файловых систем и поддержки NLS по запросу.
При подключении устройства, например, MP3-плеер, к универсальной последовательной шине (USB), ядро распознает, что устройство подключено, и генерирует событие uevent. Затем это событие обрабатывается udevd, как было описано выше.
Существует несколько возможных проблем, связанных с автоматическим созданием узлов устройств.
Udev загрузит модуль только в том случае, если у него есть
псевдоним, специфичный для шины, и драйвер шины правильно
экспортирует необходимые псевдонимы в sysfs. В других случаях следует организовать
загрузку модуля иными способами. Известно, что, начиная с версии
Linux-5.19.2, udev, выполняет загрузку правильно написанных
драйверов для INPUT, IDE, PCI, USB, SCSI, SERIO, и FireWire
устройств.
Чтобы определить, имеет ли требуемый драйвер устройства
необходимую поддержку Udev, запустите modinfo с именем модуля в
качестве аргумента. Далее, попробуйте найти каталог устройства в
/sys/bus и проверьте, есть ли там
файл modalias.
Если файл modalias существует в
sysfs, то драйвер, который
поддерживает устройство, может обращаться к нему напрямую, но не
имеет псевдонима, это ошибка в драйвере. Загрузите драйвер без
помощи Udev и ожидайте, что проблема будет исправлена позднее.
Если же в каталоге /sys/bus нет
файла modalias, это означает, что
разработчики ядра еще не добавили поддержку modalias к этому типу шины. В Linux-5.19.2 это
относится к шиной ISA. Ожидайте, что эта проблема будет
исправлена в более поздних версиях ядра.
Udev не предназначен для загрузки драйверов «обёрток», таких как snd-pcm-ossи неаппаратных драйверов, например, loop.
Если модуль «обёртка» только расширяет функциональность,
предоставляемую каким-либо другим модулем (например модуль
snd-pcm-oss расширяет
функциональность модуля snd-pcm, давая возможность звуковым
картам быть доступными для OSS приложений), настройте
modprobe для
загрузки оболочки после того, как Udev загрузит обернутый модуль.
Для этого добавьте строку «softdep» в файл, который находится в
каталоге /etc/modprobe.d/.
Например:
<filename>.conf
softdep snd-pcm post: snd-pcm-oss
Обратите внимание, что команда «softdep» разрешает добавлять pre: зависимости, или одновременно pre: и post:
зависимости. Обратитесь к документации modprobe.d(5) для изучения синтаксиса и
возможностей «softdep».
Если рассматриваемый модуль не является обёрткой, и полезен сам
по себе, настройте загрузочный скрипт modules, чтобы он
инициализировался при загрузке системы. Для этого добавьте имя
модуля в файл /etc/sysconfig/modules в отдельной строке. Этот
способ сработает и для модулей-обёрток,но не является
оптимальным.
Либо не создавайте модуль, либо занесите его в черный список в
файле /etc/modprobe.d/blacklist.conf, как это сделано
с модулем forte в примере
ниже:
blacklist forteМодули, занесенные в черный список, можно загрузить вручную с помощью явной команды modprobe.
Это обычно происходит, если правило неожиданно совпадает с другим устройством. Например, плохо написанное поставщиком оборудования правило может соответствовать как диску SCSI(искомое устройство), так и универсальному устройству SCSI (неправильно). Найдите ошибочное правило и исправьте его с помощью команды udevadm info.
Это может быть проявлением предыдущей проблемы. В ином случае,
если правило использует атрибуты файловой системы sysfs, то это может быть проблемой
синхронизации ядра, которая будет исправлена в более поздних
версиях ядра. Но вы можете обойти проблему, создав правило,
которое ожидает используемый атрибут sysfs и добавляет его к файлу правил
/etc/udev/rules.d/10-wait_for_sysfs.rules
(создайте его, если файл не существует). Пожалуйста, сообщите в
списке рассылки разработчиков LFS, если это решение вам поможет.
Дальнейший текст предполагает, что драйвер статически встроен в ядро или уже загружен как модуль, и что вы уже проверили, что Udev не создает устройство с неправильным именем.
Udev не обладает информацией, необходимой для создания узла
устройства, если драйвер ядра не экспортирует свои данные в
sysfs. Как правило, такое
происходит с внешними драйверами, которых нет в дереве исходного
кода ядра. Создайте статический узел в каталоге /usr/lib/udev/devices с соответствующими
старшим/младшим номерами (смотрите файл devices.txt в
документации по ядру или документации, предоставленной сторонним
поставщиком драйвера). Статический узел будет скопирован в
/dev с помощью udev.
Это связано с тем, что udev обрабатывает события uevents и загружает модули параллельно, а значит в непредсказуемом порядке. Это никогда не будет «исправлено». Вы не должны полагаться на то что имена устройств ядра стабильны. Вместо этого создайте свои собственные правила, которые делают символические ссылки со стабильными именами на основе некоторых неизменяемых атрибутов устройства, таких как серийный номер или вывод различных утилит *_id, установленных Udev. Смотрите Раздел 9.4, «Управление устройствами» и Раздел 9.5, «Настройка сети» для примера.
Дополнительную документацию можно получить на следующих сайтах:
Реализация пользовательского пространства в devfs
http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf
Файловая система sysfs
https://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf