Ja mam clanky pana Krcmare rad, ale tento mi prijde jako jeden z tech ne uplne povedenych. Muze to byt, ze nechtel clanek moc dlouhy, nebo ze holt nemam patricne znalosti... Cili to neni kritika clanku, spis seznam veci, kterym nerozumim.
Napr.
Proc predvidatelne nazvy? Ja jako clovek toho pri zasunuti karty do slotu moc nepredpovim, jake bude mit znaceni. Nebylo by terminologicky vhodnejsi "deterministicke"?
"Vyžaduje to zapisovatelný root, což je obecně v průběhu bootu problém." -- nerozumim duvodu, vzdyt konfiguraci by nemel byt problem ukladat pozdeji. Tim by se vyresil i problem s tim, ze zarizeni muze "vzniknout" pozdeji -- udev jako takove preci nema problem s hotplugem.
"utility v uživatelském prostoru závodí s jádrem v tom, kdo kdy přidělí rozhraní jméno" -- predpokladam, ze se zde hovori o udev a pripadne podobnych vecech. Neni mi jasne, proc se souperi, zda to jde vypnout, proc nemuze mit vice jmen pres symlinky v /sys?
"do hry vstoupí více instancí udev, přičemž device tree už je naplněný a každý paralelní udev pak uvidí jiný PCI tree" -- neni to tedy spise chyba udev? Proc by melo bezet/bezi vice instanci, navic kazda z nich s jinym device tree?
proc je pojmenovani podle lokace sbernice preferovano pred pojmenovanim dle MAC? Prijde mi, ze device tree je rozbity casteji nez se musi prekonfigurovat MAC -- navic ve spojeni s udev a hotplugem by snad nemel byt ani problem zareagovat udevem na zmenu MAC (i kdyz nevim, jestli se ta zmena verejne signalizuje).
"Vyžaduje to zapisovatelný root, což je obecně v průběhu bootu problém." -- nerozumim duvodu, vzdyt konfiguraci by nemel byt problem ukladat pozdeji.
To si nějak nedokážu představit. Systém startuje, kořenový svazek je read-only. Spustí se udev, objeví novou síťovku a chce pro ni vytvořit záznam do /etc/udev/rules.d
s persistentním pojmenováním. Co by měl udělat? Uložit si nějakou poznámku do /dev
a pak se k ní později vrátit? Jak, když už v té době nepoběží? Co když se mezitím objeví další karta a bude jí chtít přidělit stejné persistentní pojmenování? Ten problém rozhodně žádné jednoduché řešení nemá a bezestavové algoritmické pojmenování je rozhodně lepší nápad.
Udev daemon běží jen proto aby reagoval na události jádra. Když nastane nějaká událost, je obsloužena a démon se vrací k poslouchání událostí jádra.
Jistě, každý problém se pravděpodobně dá vyřešit přidáním další komplexity, otázka zní, jestli to za to stojí. Jestli má nějaký význam lpět na pojmenování eth0-n , když je možné celou komplexitu ušetřit přejmenováním na algoritmicky generovaná jména rozhraní.
Myslel jsem to tak, že si system bootuje, zkonzultuje existující pravidla a případně vytvoří pravidla nová. V /etc/RC.d je pak služba, která se zavolá buďto po nabootovani (když je root v RW) nebo při vypínání (dokud je root v RW), která zapíše pravidla. Chápu, že bezstavova konfigurace je v mnoha případech vhodnější, aleargument s RW rootem mi přijde zvláštní.
A naprosto chápu, že ten problém je složitý a nedělám si iluze, že bych ho zde v diskusi jako první vyřešil, jen říkám, že argumentace v článku mi nepomáhá.
Hned nemusi delat nic - proc by mel? Bohate staci, kdyz ten zapis/update probehne az v momente, kdy uz root r/w mas - a to snadno poznas (a to i na old-school sysvinit-based systemech, kde dependency-based boot v nejake forme fungoval uz dlouho pred tim, nez se objevil systemd). Mimoto udev beztak bezi porad, pripojovat novy HW muzes i za chodu systemu a je potreba nejaka reakce, takze argument "kdyz uz nebezi" moc validni sam o sobe neni...
To je zajimavy jak to safra ty distribuce (zarucene gentoo ale i dalsi) sakra delaly, ze jim to bez problemu fugovalo.
Gentoo si totiz pri startu (dokud to teda jeste fungovalo) prave to pravidlo pojmenovani na sitovky do udev rules vyrobilo. A kdyz pribyla nova sitovka, pribyl novy radek s ethX+1. Pokud bylo treba nazvy prehazet, stacilo pravidla upravit. Sakra, asi si to meli nechat patentovat, to je vynalez na nobelovku nejmin.
Takového hardwaru jsem zažil... Periférie cestující po sběrnici podle toho, jestli byl proveden horký nebo studený start nebo restart. Nebo HW, který měnil pořadí zařízení na sběrnici podle toho, jestli byla zapnutá virtualizace nebo nebyla. Nebo po aktualizaci BIOSu a další. Ale nebylo to nic, čím by se nedalo lehce pracovat přes udev nebo ifrename a hlavně pojmenování co je teď v systemd takové případy stejně nijak neřeší, akorát přidělává problémy další.
Pokud systém funguje většině a je dost flexibilní, aby si menšina mohla relativně snadno upravit jeho chování podle use case (*), je to přímo učebnicový příklad ne-problému, které má správné řešení nehrabat do toho vůbec, případně vylepšit ony možnosti customizace.
*) Už proto, že univerzální řešení neexistuje (důkaz sporem: U firewall appliance chci pojmenování tvaru fyzický slot+port bez ohledu na to, jestli v jiném slotu něco je strčené nebo ne, u virtuálu kde síťovka po sběrnici může cestovat, ale jejich pořadí zůstane stejné chci evidentně podle pořadí na sběrnici).
Ke svemu nazoru jste samozrejme opravnen. Ja bych jen podotknul, ze jsme na technickem serveru a v technicke terminologii ma slovo "deterministicky" peclive vymezeny vyznam tak, aby prave nebylo potreba ho prekladat jako "ocekavatelne" nebo "predvidatelne" a potom se hadat kdo ma co ocekavat nebo zda jde znaceni skutecne predvidat. Kdybych mel poskytnout vysvetleni nejakemu decku, tak bych mu rekl, ze z meho pohledu je nejblizsi slovo "nenahodne", coz vystihuje duvod, proc to zavedli -- aby odstranili problemy, kdy ruzne drivery najdou ruzna zarizeni v ruznem poradi a vyhnuli se pri pojmenovani vlivu nahody. Kazdopadne dalsi diskusi s Vami nehodlam vest, rikejte tomu jak chcete, ale az budete chtit, aby Vam v branzi lidi rozumeli, tak holt budete muset sahnout po terminologii. Prozatim tomu rikejte klidne "lehkost kreckova dechu".
Taky souhlasím s tím, že tento článek nemá obvyklou kvalitu Petra. Není mi např. jasné, proč v jedné podkapitole je "Podle fyzického umístění to nejde", když se nejedná o řešení v systemd špatně a v další podkapitole "Předvídatelné názvy", která je o řešení podle fyzického umístění, ale v systemd naopak vychvalována.