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

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

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

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

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

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

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

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

Современные ядра 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или (на старых системах) программу , которая прослушивает насчёт событий является необходимой .

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

Так что, в основном, когда дело доходит до сложности загрузки, udev, скорее всего, меньше всего вас беспокоит.

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

• Просто есть набор соответствующих chmod, chown, lnи команды таковою в скрипт , который запускается как часть начальной загрузки.
• Используйте systemd-udevменеджер plug-and-play, который является частью проекта systemd.
• Используйте Gentooeudev , который является ответвлением, systemd-udevот которого systemd теперь значительно отличается.
• Используйте Devuan'svdev , который является менеджером plug-and-play, разработанным Джудом Нельсоном, который является частью Devuan.
• Использование mdev, которое, в отличие от другого ответа, не относится к Gentoo. Это менеджер plug-and-play, который встроен в BusyBox .
• Используйте Suckless,mdev который является менеджером plug-and-play, разработанным Dimitris Papastamos.
• Используйте Laurent Bercotmdevd , который совместим с BusyBox по конфигурации, mdevно выполняет собственную обработку сокетов и не понимает протокол LISTEN.

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

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

• Лоран Берко старый s6-netlink-listenerиs6-uevent-spawner
• netlink-datagram-socket-listen и plug-and-play-event-handlerиз набора инструментов Nosh

Udev? Лучшая альтернатива - не использовать это. И, научившись не использовать его, Linux и мир * NIX начнут приобретать более логичный смысл.

Лучшая долгосрочная альтернатива - использовать статические устройства (см. Примечание). Если у вас есть драйвер, ядро ​​Linux управляет горячим подключением. Я предпочитаю никогда не бегать udevd.

Dbus это другое дело. Это замедляет вашу систему, но постоянно меняющийся мир сценаристов любит ее. Итак, многие вещи, к которым вы привыкли, такие как веб-браузеры или приложения со скриптовыми бэкэндами, должны быть исправлены (запущены или перестроены без всего этого или сброшены для другого приложения).

Примечание. Если вы просто подключаете флэш-диск или DVD-устройство, используйте, dmesg|tailчтобы увидеть название устройства для монтирования. Изучение, когда устройство является символом или блочным устройством, является фундаментальным знанием системы в мире компьютерного оборудования. В Linux это с открытым исходным кодом, проверьте это много о Linux, а не только встроенный . Это лучше для более широкого понимания прямой логики (а не философии) всех * NIX, таких как Linux (Solaris, HPUX, AIX и т. Д.).

Udev, dbus, gconf / dconf, systemd, gnome-shell, Gnome, Glib, mono и Fedora предназначены для людей с огромным количеством времени, которые не могут использовать RTFM, или хотят автоматически обновляемого, действительно скользкого (выглядящего), но более медленного чем патока, глючит, на полпути - там линукс. (Действительно ужасное место, поищите в интернете множество подобных впечатлений).

Система загружается, затем запускается udevd. Но, как утверждается, udev необходимо, потому что второстепенные номера устройства will changeпри перезагрузке. Кажется, что смысл существования Udev противоречит сам себе на каждом шагу. И где это файлы, кажется, всегда неправильно независимо от того, с кем вы консультируетесь. Не верьте или freedesktop.org.

Кроме того, что udev поглощен этим ужасом, известным как systemd, я не знаю, что тогда делать с мусорной утилитой / etc / udev. И глупо говорить, что написание правил udev лучше чем что-либо. Кажется, что люди из Gentoo хотят держаться за него и не должны иметь systemd, поэтому они разделили его на eudev.

Если вы хотите смехотворно быструю, безвкусную систему, то используйте основы Linux.