Linux - статьи



              

Linux 2.6: откуда берется пыль и куда деваются линки - часть 3


бла-бла-бла device '/sys/class/tty/ttyLTM0' has major:minor 62:64 looking at class device '/sys/class/tty/ttyLTM0': SUBSYSTEM=="tty" SYSFS{dev}=="62:64"

Параметры читаются так: q(uery), n(ode), p(ath), a(ttributes). Конечно, вы легко можете скомбинировать два вызова в одной строке через обратные кавычки или конструктив $(). Например, следующая строка выдает всю известную системе информацию о моем флэш-накопителе: #udevinfo -a -p `udevinfo -q path -n /dev/sda1`

Короче, мне достаточно к-имени — я и так доволен, тем более что драйвер не предоставил никакой другой веской информации для классификации винмодемов. Предполагается, что это PCI-устройства без поддержки hotplug. Помимо SYSFS существуют и другие ключи, такие как BUS или SUBSYSTEM,— но мне это уже совсем не надо. Учтите, если вы задаете несколько ключей поиска, они должны совпасть все вместе — так что указывайте так много ключей, сколько надо для "отсечения" вашего устройства или группы устройств.

Когда устройство найдено, с помощью правил оно будет "причесано" перед отправкой в /dev. NAME=“%k” подставляет к-имя, говоря "называй так, как хочет ядро", а точнее драйвер. Здесь же можно немного покрутить с каталогами, написав, например, NAME=“modems/%k”, или с самим именем: NAME=“momed%n” (где %n обозначает индекс, в нашем случае — 0).

Если мы не хотим задавать новое имя — значит, наше правило хочет поиграть с правами доступа или сим-линком. Право 0660 называется "себе и группе читать и писать" — это просто для понтов написано, поскольку такое право прописано по умолчанию в /etc/udev/udev.conf в параметре default_mode. Владелец устройств по умолчанию всегда root. Группа uucp занимается всякими коммуникациями, так что все нужные приложения, вроде PPP-дайлера, смогут получить доступ к модему.

В оригинальной доке советуют что-то там настраивать в permissions.d — но, как я понял, эта техника уже ушла в прошлое, такого каталога нет, а параметры владельца и файловых прав доступа вполне доступны через rules.d. При этом в скриптах есть интересный код "конвертация пермишенов в новый формат". Правильно — ну его, всё в один файл, в одну строку. Устройство ttyLTM0 в SYSFS создаст наш драйвер модема, например, по modprobe ltserial, который мы пока даже не поставили. Да, именно так — стартуем модуль ltserial, а модем там тоже окажется, скоро увидим почему.

Мы проследили путь с конца: от сим-линка и имени устройства в /dev до /sys и далее — до драйвера. Теперь закончим это расследование в обратном направлении, чтобы вы могли пользоваться результатом практически.

В последнее время драйвер любого "нештатного" устройства представляет собой модуль, загружаемый сервисом modprobe. Несмотря на вялое сопротивление сторонников монолитного ядра, идея динамического "уровня 0" вокруг мини-ядра — так, как это сделано в QNX (хотя это не совсем точно — в QNX модули не располагаются в L0),— постепенно становится стандартом де-факто. Впрочем, хорошо, конечно, когда есть выбор. Кое-что действительно не имеет смысла загружать динамически.

Вообще-то, модуль загружает само ядро, и отчет об этом помещается в файл /var/log/dmesg — для его просмотра даже существует специальная утилита dmesg, так что можете просто запускать ее. Утилита modprobe используется только для загрузки модулей в самом общем смысле: сначала исследуются зависимости модуля, в том числе и "зависимости зависимостей", после чего загружаются все модули, необходимые для загрузки указанного.

В нашем случае для "создания" устройства в SYSFS достаточно в любой момент (удачно) выполнить загрузку драйвера modprobe ltserial. Модули расположены в каталоге "модули текущей сборки" — или, как это часто пишут, /lib/modules/`uname -r`, где uname -r возвращает "релиз" ядра. Например, в случае текущей сборки Fedora Core 4 это значение будет “2.6.11-1.1369_FC4”. Вы можете выполнить эту команду и убедиться, что на релиз легче ссылаться, как на uname -r :).

Поскольку модули могут зависеть друг от друга через внешние ссылки (так называемые внешние символы, экспортируемые через декларации EXPORT_SYMBOL), то для загрузки модуля система должна знать о таких связях. В целях оптимизации (поиск всех внешних символов во всех библиотеках — задача не скорая) данная информация кэшируется в файле modules.dep, располагающийся в корневом каталоге модулей, путь к которому мы только что обсуждали. Этот файл является текстовым, с очень простым форматом, так что вы легко можете его исследовать. Утилита modprobe ожидает, что modules.dep находится в актуальном состоянии. Для этого после "заброски" новых модулей и перед запуском (явным или неявным, при перезагрузке) modprobe нужно выполнить depmod -a — это обновит modules.dep. Конечно, это надо проделать только один раз.

Допустим, что у нас уже есть два нужных модуля (мы-то движемся с конца): ltmodem.ko и ltserial.ko. Скопируем их в какое-нибудь приметное место внутри каталога модулей, например в /lib/modules/`uname -r`/extra. Выполним обновление зависимостей depmod -a и убедимся, что в modules.dep появились строки: /lib/modules/2.6.11-1.1369_FC4/extra/ltserial.ko: /lib/modules/2.6.11-1.1369_FC4 /extra/ltmodem.ko /lib/modules/2.6.11-1.1369_FC4/extra/ltmodem.ko:




Содержание  Назад  Вперед