Existují alternativy k použití `udev`?

K udev existují různé alternativy tam venku. Zdá se, že Gentoo může používat něco, co se nazývá mdev . Další možností by bylo pokusit se použít udev předchůdce devfsd . Nakonec můžete pomocí mknod vždy vytvořit všechny soubory zařízení, které potřebujete .

Všimněte si, že s posledně jmenovaným není nutné vytvářet vše při bootování, protože uzly lze vytvořit na disku a ne v dočasném souborovém systému jako u ostatních možností. Samozřejmě ztratíte flexibilitu dynamicky vytvářených souborů zařízení, když je připojen nový hardware (např. USB klíčenka). Věřím, že standardním přístupem v této éře bylo mít každý soubor zařízení, který byste mohli rozumně potřebovat, již vytvořený pod /dev (tj. mnoho souborů zařízení).

Samozřejmě, že obtížnost přimět některý z těchto přístupů k fungování v moderním distru je pravděpodobně poměrně vysoká. Wiki Gentoo zmiňuje potíže při získávání mdev pracovat s desktopovým prostředím (natož mimo Gentoo). Poslední devfsd vydání bylo 2002, netuším, jestli to bude vůbec fungovat s moderními jádry. Ruční vytváření uzlů je pravděpodobně nejschůdnější přístup, ale dokonce i zakázání udev může být problém, zvláště v distos používajícím systemd (udev je nyní součástí systemd , což naznačuje silnou závislost).

Moje rada je držet se udev;)

Moderní linuxová jádra podporují devtmpfs file system , který dynamicky vytváří všechny uzly zařízení, jakmile je jádro objeví. (Ve skutečnosti nejnovější udev vydání vyžadují tento; zjistíte, že udev již nevytváří žádné uzly zařízení, pouze symbolické odkazy.)

Podobně bylo načítání firmwaru přesunuto také do jádra, takže zbývají pouze úlohy udev provádí načítání modulů (podle modalias) a použití oprávnění zařízení a dalších pravidel udev.

Teoreticky by se tedy plně monolitické jádro mělo nabootovat v pohodě bez udev.

Skutečným problémem je však to, co se stane později.

1. Poměrně mnoho programů v uživatelském prostoru se spoléhá na to, že udev udržuje databázi zařízení přístupnou přes libudev . Zatímco výčet zařízení a poslech přidaných/odebraných událostí lze provést přímo pomocí rozhraní jádra (sysfs a netlink), stále zůstanete bez všech metadat, která jsou připojena různými pravidly udev.

2. Pravidla udev také udržují různé "trvalé" symbolické odkazy v /dev/disk/by-* , /dev/mapper , /dev/input/by-path , /dev/snd/by-path , a tak dále. Pokud máte například připojeny dva disky, není zaručeno, že první bude vždy sda nebo sdb , ale udev zajišťuje, že symbolické odkazy jsou v /dev/disk/by-uuid bude i nadále ukazovat na ten správný.

3. I když jsou uzly zařízení nyní vytvářeny jádrem, a proto už vás to nezajímá, je stále důležité poznamenat, že některé typy zařízení začaly používat dynamicky přidělovaná hlavní/vedlejší čísla, takže i když máte /dev/fuse jako 10 228 a /dev/hpet jako 10 229 dnes, budou mít různá čísla po každém restartu, takže buď devtmpfs nebo (na starších systémech) je vyžadován program, který poslouchá uevents .

Mnohé z těchto věcí lze snadno provést jinými programy, jako je mdev , samozřejmě. Jde mi o to, že statický /etc/MAKEDEV skript už nebude fungovat...

Takže v podstatě, pokud jde o složitost bootování, udev je dost pravděpodobně nejmenší vašich obav.

Existuje několik alternativ:

• Stačí mít sadu vhodných chmod , chown , ln a podobné příkazy ve skriptu, který se spouští jako součást bootstrapu.
• Použijte systemd-udev , správce plug-and-play, který je součástí projektu systemd.
• Použijte Gentoo eudev , což je větev systemd-udev od kterého se systemd nyní výrazně odchýlil.
• Použijte Devuanův vdev , což je plug-and-play manažer vyvinutý Judem Nelsonem, který je součástí Devuan.
• Použijte mdev , což na rozdíl od jiné odpovědi není věc Gentoo. Je to správce plug-and-play, který je zabudován do BusyBox.
• Použijte Suckless mdev což je plug-and-play manažer vyvinutý Dimitrisem Papastamosem.
• Použijte mdevd Laurenta Bercota , což je konfigurace kompatibilní s BusyBoxem mdev ale zpracovává vlastní soket a nerozumí protokolu LISTEN.

Všechny tyto, kromě prvního, vyžadují sady pravidel popisujících, jak reagovat na události oznámení jádra o zařízeních. Samozřejmě.

Existují také nástroje, které převezmou programy určené pro /proc/sys/kernel/hotplug , jako jsou dva mdev s, a to je přizpůsobí a serializuje poslechem síťového soketu a poté vytvoří tyto programy:

• Starý s6-netlink-listener Laurenta Bercota a s6-uevent-spawner
• netlink-datagram-socket-listen a plug-and-play-event-handler ze sady nástrojů pro nos