☰

Есть ли альтернативы использованию `udev`?

tag-icon • tag-icon linux devices udev
Есть ли альтернативы использованию `udev`?

Хотя я понимаю величие udev и ценю усилия разработчиков, мне просто интересно, есть ли ему альтернатива.

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

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

решение1

Современные ядра Linux поддерживают devtmpfsфайловую систему (не путать с древней devfs) , которая динамически создает все узлы устройств, как только ядро ​​их обнаруживает. (На самом деле, последние udevвыпускитребовать(Вы обнаружите, что udev больше не создает никаких узлов устройств, а только символические ссылки.)

Аналогично загрузка прошивки также была перенесена в ядро, поэтому единственными оставшимися задачами udevявляются загрузка модулей (в соответствии с модальностями) и применение разрешений устройств и других правил udev.

Таким образом, в теории полностью монолитное ядро ​​должноботинокпрекрасно обходится и без udev.

Однако настоящая проблема заключается в том, что происходит дальше.

  1. Довольно много программ пользовательского пространства полагаются на udev, поддерживающий свою базу данных устройств, доступную через libudev. Хотя перечисление устройств и прослушивание добавленных/удаленных событий можно выполнять напрямую с помощью интерфейсов ядра (sysfs и netlink), вы все равно останетесь без всех метаданных, которые прикрепили различные правила udev.

  2. Правила udev также поддерживают различные «постоянные» символические ссылки в /dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-path, и т. д. Например, если у вас подключены два диска, нет гарантии, что первый из них всегда будет sdaили sdb, но udev гарантирует, что символические ссылки в /dev/disk/by-uuidпродолжат указывать на правильный.

  3. Хотя узлы устройств теперь создаются ядром и, следовательно, больше не должны вас беспокоить, все равно важно отметить, что некоторые типы устройств начали использовать динамически назначаемые основные/вспомогательные номера, поэтому даже если у вас сегодня есть /dev/fuse10 228 и /dev/hpet10 229, ониволяимеют разные номера после каждой перезагрузки, поэтому либо devtmpfs(в старых системах) программа, которая прослушивает uevents,необходимый.

Многие из этих вещей можно было бы легко сделать с помощью других программ, таких как mdev, конечно. Я хочу сказать, что статический /etc/MAKEDEVскрипт больше не будет работать...

Итак, в принципе, когда дело касается сложности загрузки, udev, скорее всего, являетсянаименееваших опасений.

решение2

Существуют различные альтернативы udev. Похоже, Gentoo может использовать что-то под названиемmdev. Другим вариантом было бы попытаться использовать udevпредшественника devfsd. Наконец, вы всегда можете создать все необходимые вам файлы устройств с помощью mknod.

Обратите внимание, что в последнем случае нет необходимости создавать все во время загрузки, поскольку узлы могут быть созданы на диске, а не во временной файловой системе, как в других вариантах. Конечно, вы теряете гибкость динамически создаваемых файлов устройств при подключении нового оборудования (например, USB-накопителя). Я считаю, что стандартным подходом в эту эпоху было иметь все файлы устройств, которые вам могли бы понадобиться, уже созданными /dev(т. е. множество файлов устройств).

Конечно, сложность в том, чтобы любой из этих подходов работал в современном дистрибутиве, вероятно, довольно высока. Вики Gentoo упоминает о трудностях в работе mdevс окружением рабочего стола (не говоря уже о других, кроме Gentoo). Последний devfsdрелиз был 2002 года, я понятия не имею, будет ли он вообще работать с современными ядрами. Создание узлов вручную, вероятно, является наиболее жизнеспособным подходом, но даже отключение udevможет быть проблемой, особенно в дистрибутивах, использующих systemd( udevтеперь является частью systemd, что предполагает сильную зависимость).

Мой совет - придерживайтесь udev;)

решение3

Есть несколько альтернатив:

  • Просто добавьте набор соответствующих команд chmod, chown, ln, и тому подобных в скрипт, который запускается как часть начальной загрузки.
  • Используйте systemd-udevменеджер plug-and-play, который является частью проекта systemd.
  • ИспользоватьGentoo'seudev, который является ответвлением, systemd-udevот которого systemd теперь значительно отклонился.
  • ИспользоватьДевуанvdev, представляющий собой менеджер plug-and-play, разработанный Джудом Нельсоном и являющийся частью Devuan.
  • Используйте mdev, который в отличие от другого ответа не является особенностью Gentoo. Это менеджер plug-and-play, который встроен вBusyBox.
  • ИспользоватьНесосущийmdevкоторый представляет собой менеджер «plug-and-play», разработанный Димитрисом Папастамосом.
  • ИспользоватьЛорана Беркоmdevd, который по конфигурации совместим с BusyBox, mdevно выполняет собственную обработку сокетов и не понимает протокол LISTEN.

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

Существуют также инструменты, которые берут программы, разработанные для /proc/sys/kernel/hotplug, например, двух mdevs, и адаптируют и сериализуют их, прослушивая сокет netlink, а затем порождая эти программы:

решение4

Это старо, но я хочу зафиксировать свое решение здесь для тех, кто ищет напрасно.
Избежать udev непросто. Исключение DEVTMPFS из конфигурации не мешает ядру монтировать RAM-диск на /dev и заполнять его. К сожалению, это не создает необходимые точки монтирования /dev/shm и /dev/pts. Необходимо добавить devtmpfs.mount=0 к аргументам загрузки.

Связанный контент