Vlákno názorů k článku
Jak události mění Linux

Přechod na udev byl bolestný a nepříjemný. Jednoduchá struktura statických souborů reprezentujících zařízení v systému byla nahrazena změtí pravidel, ve kterých se vyznat je nad síly mnoha uživatelů.

Kdyby byla ta struktura opravdu tak jednoduchá a praktická, tak by nejspíš nebyl důvod udev vůbec napsat, natož na něj přecházet...

Pravda - ten bordel v statickom /dev bol hrozny. Tisice zbytocnych suborov a tie, ktore som potreboval, akurat chybali.

Kdyz chybely, stacilo kouzelne sluvko mknod. Pripadne makedev.
Rozhodne to bylo jednodussi nez se hrabat v neprehledne zmeti pravidel udev a jeste muset doufat, ze to pak udela to co jsme zamysleli.

Na OpenSuSE 9.3 tam těch souborů bylo přes 9000. Greg Kroah Hartman uvádí, že na nějaké konkrétní verzi Red Hatu to bylo asi 18000. To vám připadá přehledné a jednoduché? Porovnám-li to s 800 pravidly, z nichž dvě třetiny má na svědomí libsane a která jsou okomentovaná a roztříděná do jednotlivých souborů podle toho, čeho se týkají, nevím, nevím...

Vezmu-li navíc v úvahu, že čím dál víc zařízení jádro nemůže persistentně pojmenovat už z principu, je udev logickým a v podstatě nutným východiskem.

Eh, samozřejmě SuSE Linux 9.3, tahle verze ještě nebyla Open... :-)

No ja bych to srovnaval s devfs, ktery z pohledu uzivatele proste fungoval bez jakychkoliv potizi. Oproti tomu udev zavisi na pomerne krehke kernel-udev kooperaci, ktera se muze snadno rozbit pri upgradu na novou verzi jadra nebo udevu (oboje se mi osobne stalo). Krom toho udev vyzaduje netrivialni konfigurak, aby fungoval tak jak se ocekava. Oproti tomu devfs fungoval spravne bez jakekoliv konfigurace (sice s jinym pojmenovanim zarizeni, ale na to se da zvyknout).

Pokud vím, udev vznikl primárně jako reakce na to, že se devfs neosvědčil. A taky na to, že pořádně nefungoval a poté, co se o něj přestal starat původní autor, nenašel se nikdo, kdo by ho byl ochoten dát dopořádku nebo aspoň udržovat. Hlavní problém vidím v tom, že vzhledem k implementaci v jádře byl prakticky nekonfigurovatelný, takže mi není jasné, do jaké míry (pokud vůbec) mohl zajišťovat persistenci jmen zařízení.

Používala vlastně devfs nějaká jiná běžná distribuce než Mandrake?

> Hlavní problém vidím v tom, že vzhledem k implementaci v jádře byl prakticky nekonfigurovatelný, takže mi není jasné, do jaké míry (pokud vůbec) mohl zajišťovat persistenci jmen zařízení.

Mohl to delat stejne jako udev - existoval demon devfsd, ktery vytvarel konfigurovatelne symlinky na zarizeni. Takze zarizeni melo kanonicke jmeno, ktere existovalo vzdy, a navic pripadne userspace-konfigurovatelne aliasy (symlinky). K tomu bych dodal:

- odpada problem s usporadanim cinnosti pri bootu, kdy mnoho programu proste ocekava existujici zarizeni v devu. Takze treba je problem, co spoustet driv - udev nebo syslog (pro logovani udevovych hlasek)? Casto se to resi hacky jako nezbytnou pritomnosti statickych souboru, ktere se pred startem udevu premountuji tmpfs.

- I s pouzitim udevu se obvykle pouziva princip kanonicke jmeno + symlinky, uz treba jenom proto, ze kdyby udev zavedl nejake sve jmeno, tak jadro o nem nevi a vypisy jadra a jaderne struktury (/sys) by porad pouzivaly stare jmeno.

> Používala vlastně devfs nějaká jiná běžná distribuce než Mandrake?

Debian ho pouzival.

Nemyslim, ze by neprehlednost souvisela s mnozstvim. I kdybych mel specialnich souboru treba 100000, porad by to byly primitivni specialni soubory na kterych nejde prakticky nic pokazit. Chapu pochopitelne do urcite miry duvody a uvahy, ktere vedou k podobnym vecem jako je udev. Bohuzel ale konstatuji, ze prakticke provedeni je zbytecne neunixove komplikovane a stava se zdrojem spousty mnohdy velmi trapnych problemu.
Asi je to tim, ze jsem s unixy delal uz v dobe, kdy vetsina zdejsich ctenaru jeste ani nevedela, ze existuje nejaky Linux (a on tenkrat byl vlastne jen mimino). Z tohoto duvodu jsou mne proti srsti napr. i fanaticke vykriky, jak je napr. svatokradezne na Linuxu pouzit prikaz ifconfig. Kdyz jej nekdo pouziva s vedomim toho co tento prikaz na soucasnem Linuxu muze a co ne, neni duvod neustale pořvávat, ze pane Kubecek...
Zpatky k veci. Coz takove udev, to se da jeste skousnout a jak pisi vyse, pochopit. Horsi zalezitosti je HAL. Nic neunixovejsiho jsem snad na Linuxu jeste nevidel. Neprehledne, komplikovane, spatne zdokumentovane, mnohdy si to dela co chce....Budme stastni, ze se toho lze porad jeste pomerne snadno zbavit.

Nemyslim, ze by neprehlednost souvisela s mnozstvim. I kdybych mel specialnich souboru treba 100000, porad by to byly primitivni specialni soubory na kterych nejde prakticky nic pokazit.

Ani na starém ext2 bez indexovaných adresářů to není problém? Ani na embedded systémech? Ani na rescue systému?

Asi je to tim, ze jsem s unixy delal uz v dobe, kdy vetsina zdejsich ctenaru jeste ani nevedela, ze existuje nejaky Linux (a on tenkrat byl vlastne jen mimino).

V mém případě se první zkušenosti s unixovými systémy datují do roku 1992. Ale to neznamená, že se budu dívat na všechno, co tu v roce 1992 nebylo, jako na neunixové novoty, které je třeba zadupat do země.

Z tohoto duvodu jsou mne proti srsti napr. i fanaticke vykriky, jak je napr. svatokradezne na Linuxu pouzit prikaz ifconfig.

To není svatokrádežné, to je jen hloupé. Používat ke konfiguraci jaderných objektů rozhraní založené na koncepci, která už 9 let v jádře není, které mi podle nálady někdy ukazuje neexistující objekty, jindy neukazuje existující a občas pro zpestření na požadavek na operaci s objektem A provede tuto změnu bez varování na objektu B (protože A ve skutečnosti neexistuje a příkaz jeho existenci pouze předstírá), to je ten váš "unixový přístup"? Ten náboženský přístup a obvinění ze svatokrádežnosti jsou ve skutečnosti typické spíše pro lidi, kteří uvažují jako vy, lidé, kteří se zuby nehty brání jakékoli změně a každý pokus o novou koncepci šmahem odmítají jako "neunixový".

Horsi zalezitosti je HAL. Nic neunixovejsiho jsem snad na Linuxu jeste nevidel.

A jsme zpátky u toho hlavního problému: čím se měří ta unixovost? Tím, jestli to vymysleli v 70. letech nebo až v 80.?

Neprehledne, komplikovane, spatne zdokumentovane, mnohdy si to dela co chce...

Připadá vám přehlednější a méně komplikované zjišťovat informace o hardwaru přes deset různých rozhraní na deseti různých místech? Špatně zdokumentované... kéž by bylo všechno zdokumentované aspoň tak špatně jako HAL. Mnohdy si dělá co chce... také jsem měl párkrát ten pocit, i od plic jsem si zanadával. Jenže nakonec jsem pokaždé zjistil, že chyba byla na mé straně.

Nehodlam zakladat flamewar, takze nebudu ani obsahle reagovat, ac je na co.
Snad jen ten ifconfig. Pokud vam nekdo bude tvrdit, ze je rozumne ifconfigem treba nastavovat nekolik IP adres k jednomu ethernetu, slusne mu reknu, ze to je blbost. Kdyz mne nekdo rekne, ze pomoci ifconfigu si nastavuje narychlo IP adresu na rozhrani pres ktere chce treba zkopirovat data mezi 2 PC (ma je polozena vedle sebe doma pod stolem) a ze to dela proto, ze se mu proste s timto prikazem dela lepe a ma jej zazity, tak na nej nebudu fanaticky pořvávat. To je cely ten rozdil.

Osobne ifconfig pouzivam hlavne na vypis adres rozhranni, protoze mi prijde mnohem prehlednejsi nez ip addr.