Чи існують альтернативи використанню `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/fuseяк 10,228, так і /dev/hpet10,229, вони будуть мають різні номери після кожної перезавантаження, так як devtmpfsабо (на старих системах) програму , яка прослуховує щодо подій є необхідною .

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

Отже, в основному, якщо мова йде про складність завантаження, udev - це, ймовірно, найменше з ваших проблем.

Є кілька альтернатив:

• Просто є набір відповідних chmod, chown, lnі команди таковою в скрипт , який запускається як частина початкового завантаження.
• Використовуйте systemd-udev, менеджер підключення та відтворення, який є частиною системного проекту.
• Скористайтеся Gentoo'seudev , що є systemd-udevроздрібною силою, від якої systemd тепер значно розходився.
• Використовуйте Devuan'svdev , який є плагін-ігровим менеджером, розробленим Джудом Нельсоном, який є частиною Devuan.
• Використання mdev, що суперечить іншій відповіді, не є річчю Gentoo. Це диспетчер плагінів, який вбудований в BusyBox .
• Використовуйте Suckless,mdev який є менеджером з підключенням, розробленим Димитрісом Папастамосом.
• Використовуйте Лоран Беркотmdevd , який є конфігурацією, сумісною з BusyBox, mdevале він має власну обробку сокета і не розуміє протокол LISTEN.

Усі вони, крім першого, вимагають набору правил, що описують, як реагувати на події сповіщення ядра щодо пристроїв. Очевидно.

Є також інструменти, які приймуть програми, розроблені для /proc/sys/kernel/hotplugтаких, як два mdevs, і які адаптують і серіалізують їх, прослуховуючи сокет з мережею зв'язку, а потім нерестуючи ці програми:

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

удев? Найкраща альтернатива - не використовувати його. І навчившись не користуватися ним 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, або бажають автоматично оновити дійсно гладкий (дивлячись), але, повільніше ніж меляса, баггі, напівдорога Linux. (По-справжньому жахливе місце, погляньте в Інтернеті, щоб отримати багато подібних вражень).

Потім завантажується система udevd. Але, як стверджується, udev необхідний тому, що пристрої незначні числа will changeпри перезавантаженні. Здається, причина Удева на кожному кроці суперечить собі. І де це файли, здається, завжди неправильно, незалежно від того, з ким ви консультуєтесь. Не довіряйте або freedesktop.org.

Крім того, що udev поглинається тим жахом, відомим як systemd, я не знаю, що тоді робити з sme / one / etc / udev. І говорити про те, що писати правила udev якось краще, ніж все що завгодно. Люди, начебто, хочуть звисати до нього і не повинні мати системний характер, тому вони віддалили його на eudev.

Якщо ви хочете, щоб насмішкувато швидка, неприємна система здивувань, використовуйте основи Linux.