[sisyphus] Новости о udev. [JT]

[Alexey Morozov]

В общем, как говаривал один наш мохнатый друг сомнительного
происхождения, "мы строили, строили и наконец...".
Можно ли в данном случае употребить совершенную форму глагола,
я не уверен (приписка: пока писал, удостоверился, что нельзя ;-)),
но в

salto:/raid/OUT/Daedalus/

отправлены udev-0.50-alt2, modules_lookup-1.0-alt1, а Антон Фарыгин
должен был залить kernel-feat-fs-tmpfs-lookup-traps.

Что это дает прогрессивной общественности, к коей, несомненно,
причисляет себя подавляющее большинство пользователей ALT Linux?
Сейчас поясню. Многие из тех, кто решил почувствовать себя на, эгхм,
гребне линуксовой моды и поставить себе udev в добавление к своему
модному ядру 2.6, успели заметить, что некоторые их дивайсы "бесследно
исчезли" (tm). Теперь заваливают меня письмами и личными обращениями,
требуют вернуть дивайсы взад. Я, в общем, не Копперфильд, и даже не
учусь на него, но остаться безучастным к столь убедительным просьбам не
мог. В итоге я собрал пакет с ядерным патчем
(kernel-feat-fs-tmpfs-lookup-traps), написал для него скриптовую
обвязку (modules_lookup) и внес в udev (0.50-alt2) необходимые правки.
Часть проблем осталась, но, не не менее, угнетенные [нынешним положением
дел] теперь смогут вздохнуть спокойнее :-).

Судя по развернувшейся бурной переписке между интересующимися и вашим
покорным слугой, не помешает, однако, вначале изложить некоторую теорию,
чтобы предварить ваши вопросы моими ответами.

Как вообще работала и работает система загрузки модулей и взаимодействия
с устройствами?

В старом добром ядре линукса (1.2.13 навсегда!), когда мужчины были
мужчинами, крокодилы летали выше, а слово плаг-энд-плэй
обычно произносилось на германский манер "плюг-унд-глюк" и означало
непристойное ругательство в сторону ОС Windows компании Microsoft,
не было никакой специальной поддержки устройств, подсоединяемых без
выключения компьютера.

Но уже тогда, на заре цивилизации, у ядра линукса были динамически
загружаемые драйвера устройств, некоторым из которых были приписаны
"виртуальные устройства", device inodes - псевдо-файлы, характеризующиеся
типом устройства (блочным или символьным) и двумя числами: MAJOR и MINOR
(Прим: точное значение этих заклинаний потерялось во тьме веков, остались
лишь толкования разной степени достоверности, будем считать что MAJOR
отвечает за тип устройства, а MINOR - за номер устройства среди ему подобных).

Итак, каждому существовавшему тогда типу устройств был приписан один
или несколько MAJOR'ов и довольно много MINOR'ов, и жизнь казалась
прекрасной. Как и IP-адреса, в те счастливые времена MAJOR'ы и, в
особенности, MINOR'ы раздаваись направо и налево, и счету им,
казалось, не было. Все возможные файлы устройств создавались в
каталоге /dev заранее, и появление нового типа устройств сопровождалось
народными гуляниями и приуроченному к ним выходу программы MAKEDEV,
обладавшей сокровенным знанием о принадлежности MAJOR'ов и MINOR'ов тем
или иным устройствам.

Для удобства пользователей мудрые отцы-основатели Линукса даже придумали
способ, когда обращение к файлу устройства почти магически приводило
к загрузке ассоциированного с ним модуля драйвера этого устройства,
если такой драйвер не был загружен до этого. Делалось это при помощи
функциональности ядра и программ пакета modutils, в частности, modprobe.
Эти программы, ориентируясь на MAJOR (и, иногда, MINOR) файла устройства,
отыскивали по базе, находящейся в /etc/modules.conf, подходящий для этого
устройства драйвер и загружали его.
Полустертые записи в /etc/modules.conf (иногда /etc/conf.modules) вида

alias char-major-195 nvidia

или

alias char-major-14 soundcore

как раз и указывают на то, что владелец данного компьютера являлся
счастливым обладателем звуковой подсистемы или видеокарты компании
Нвидия, модули которых требуется загрузить при обращении к соответствующим
устройствам. Жизнь линуксоводов была полна радости и праздника, только 
изредка прерываясь вопросами наиболее несведущих неофитов относительно
странных требований различных программ: http://tinyurl.com/3mylq

Однако уже тогда наиболее прозорливыми детьми своего времени было замечено,
что и MAJOR'ы, и MINOR'ы ограничены в своих значениях 0 снизу и 255 сверху.
А это означало, что по мере приближения к светлому компьютерному будущему 
мы, прогрессивное сообщество пользователей линукса, довольно быстро
лишим себя возможности использовать новые типы устройств, т.к. для них
не останется свободных, еще незарезервированных номеров. Эти мужественные
люди взвалили на себя решение этой насущной проблемы, грозившей
поставить под удар не только будущее Линукса, но и самих линуксоидов.
Они решили, что ограничения, налагаемые несправедливо маленькой емкостью
байта, необходимо сломать, и каждое устройство отныне должно
ассоциироваться не с безличными цифрами, а красивыми, радующими глаз
именами, вроде /ide/host0/bus0/target0/lun0/part1 (что знаменовало собой,
кажется, первый раздел жесткого диска IDE, подключенного как мастер на
первом IDE-контроллере). 

Более того, они пошли дальше в своих исканиях, и заявили, что нет никакой
необходимости держать у себя на диске файлы устройств, которых,
возможно, нет и никогда не будет у данного конкретного пользователя этого
обновленного линукса. Вместо этого каждое обнаруженное устройство должно
было регистрироваться особым образом в системе, а та, при помощи новой
замечательной виртуальной файловой системы devfs, должна была создавать
в /dev требуемые файлы устройств, чтобы благодарные пользователи линукса
могли ими воспользоваться.

Однако новая схема породила новые вопросы. Если файла устройства
еще не существует в тот момент, когда его драйвер не загружен, то как же
может система определить, что пользователю, запросившему доступ,
например, к /dev/sound требуется загрузка именно звуковых модулей.
Был изобретен механизм, ставший неотъемлемой частью devfs, так называемый
devfsd. Эта программа умела опознавать устройства по именам, и загружать
необходимые для них модули. И счастье вновь воцарилось в этом замечательном
мире.

Впрочем, на этот раз покой не был продолжительным и безмятежным.
К сожалению, новые механизмы оказались не столь удачным, какими они
представлись вначале. "Глядящий вдаль редко смотрит себе под ноги".
Так случилось и на этот раз. Несмотря на всю привлекательность идеи devfs,
её конкретное воплощение оставляло желать много лучшего в глазах самых
главных из людей. Светлое будущее, казалось бы, уже совсем
приближенное стараниями подвижников, на поверку оказалось не лишено
изъянов. Эти изъяны и стали причиной официального отказа от devfs,
и линукс на некоторое время почти погрузился в пучину печали и
неопределенности.

Но нашлись люди, сумевшие поднять упавшее было знамя. Случилось это,
однако, в другом конце мира Линукс. Наводнившие рынок устройства,
буквально кричащие: "воткни меня! ты не пожалеешь!" постепенно вытеснили
старые добрые, проверенные временем решения, где конфигурация компьютера
не менялась от его рождения до самой его почетной смерти от прогорания
дорожек на материнской плате или магнитных головок, упавших под грузом лет
на блины жестких дисков.

Новые конфигурации требовали от операционной системы немедленной реакции
на втыкание, и, что еще страшнее, вытыкание устройства. Отшлифованные в
Unix технологии размонтирования дискеты перед её извлечением (уклонявшиеся
от выполнения данного ритуала наказывались немедленными kernel panic'ами)
подвергнуты поруганию и растоптаны. Сообщество было поставлено перед
необходимостью дать свой ответ засилью "сунул-вынул" устройств. Ответ этот
назвали hotplug (Прим: вероятно, в честь эффекта повышения температуры в
месте подключения от трения при последовательном втыкании и вытыкании
устройств. Впрочем, на этот счет существуют и другие гипотезы,
обсуждение которых выходит за рамки данного обзора)

Однако со временем hotplug перерос благородные цели, поставленные его
создателями. Было замечено, что, используя функциональность hotplug, можно
построить механизм, который, подобно devfs, будет динамически создавать
файлы устройств по мере их регистрации в системе. Этому механизму дали
гордое имя udev, которое берет свое начало от вежливого требования
создать устройство на языке Суахили. udev должен был стать тем золотым
контактом в длинной и подчас непредсказуемой (#5852) цепи событий,
происходящих между втыканием устройства в предназначенный для него
разъем и возможностью воспользоваться им.

К счастью для всех нас, udev задумывался, как система, делающая только
одно дело, но делающая его хорошо. Каждый, однако, знает, что от
задумки до её воплощения лежит длинная и извилистая дорога. Но одно
можно сказать наверняка: udev действительно способен выполнять только
одну задачу - создание файлов устройств. Другая, не менее актуальная
для многих пользователей задача - автоматическая загрузка модулей в тот
момент, когда возникла нужда в их использовании, - оставалась до
последнего времени нерешенной http://tinyurl.com/62y6q.

Но не дремлет око пытливых разработчиков ядра. Путем не очень сложных
модификаций, ведущая файловая система нашего времени, tmpfs, получила
замечательную способность: если обнаруживается, что какого-либо нужного
файла еще нет, что ж, не беда, он будет создан, причем, не абы как,
а при помощи программы, указанной предусмотрительным пользователем при
монтировании данной файловой системы. Не счесть возможностей,
открывающихся перед изобретательным умом, вооруженным таким
замечательным средством. Одной из таких возможностей стала загрузка
модулей для устройств, не имеющих еще отображения на файловую систему.
Как по мановению волшебной палочки в /dev возникают /dev/cdrom,
/dev/ppp и масса других, не менее полезных пользователям устройств.

Впрочем, как известно наиболее страстным поклонникам меда, в каждой его
бочке есть ложка дегтя. Некоторые из модулей, отвечающих за жизненно
важные функции любого компьютера, пока делают свою работу не слишком
хорошо. Так, модуль 8250.ko, отвечающий за работу с последовательным
портом, просто не успевает зарегистрировать все положенные устройства в
отведенное ему время (Прим: причины этого явления еще предстоит
исследовать будущим поколениям разработчиков и пользователей). Поэтому
для таких модулей-отщепенцев создан еще один механизм: статических
файлов устройств в /etc/udev/devices. Будучи созданными там, например,
при помощи команды /sbin/MAKEDEV -d /etc/udev/devices <devname>, эти
устройства будут копироваться в файловую систему /dev при каждом запуске
сервиса udevd. 

Казалось бы, остается только радоваться, но и это решение можно считать
лишь временным. Прокрустовы ограничения на максимально возможное
количество MAJOR'ов и MINOR'ов до сих пор не преодолены. Командный центр
разработки ядра линукс принял неожиданное для простых пользователей
решение: складывавшаяся годами система назначения номеров устройствам
должна быть разрушена. В скором будущем исчезнет казавшаяся незыблемой
связь между блочным устройством с номерами (3, 1) и первым разделом
первого IDE-диска. Освященные временем заклинания из /etc/modules.conf
потеряют свою актуальность. Для каждого конкретного компьютера будет
существовать свой, уникальный набор номеров устройств, и этот набор
будет меняться по мере добавления нового и удаления отжившего свой век
оборудования. Хуже того, коварный план предусматривает, что какой-то
период времени номера зарегистрированным устройствам будут назначаться
полностью случайно при каждой перезагрузке, чтобы разнообразить и без
того не слишком унылую жизнь пользователей линукса. Но прогресс, как
известно, требует жертв, пусть случайных и практически невинных. Только
двигаясь вперед, мы сможем уйти от счастливого, но темного прошлого
к светлому будущему.

Конец.

P.S. Не смотрите на меня так. У меня грипп, болит голова и ничем умным
заниматься все равно не получается. К тому же мне, наконец, вернули
диск с Неверхудом, ну и... Больше не буду.

P.S.S. Юрий, вы сами просили подробного отчета о том, "кто виноват".
Надеюсь, вы удовлетворены

P.S.S.S. Тем, кому лень читать весь этот графоманский бред, но очень
хочется настроить новые утилиты, см. /etc/udev/udev.conf (последние
строчки), /etc/modules_lookup.conf и ченджлог к udev. Идеологически
правильнее описывать привязку устройств к модулям через
/etc/modules_lookup.conf, но работает не всегда, поэтому оставлен способ
с /etc/udev/devices/.

P.S.S.S.S. Виталь, Юрий, мне все равно перебирать udev из-за проблем с
gcc-3.4, пришлите мне, пожалуйста, те изменения и патчи, которые у вас
там образовались. Ну, и жду правильного hal.