Názory k článku
Správce Wi-Fi ovladačů v Linuxu odstoupil z funkce

Nicméně v současném stavu tu máme firmy, které se na psaní ovladačů pro Linux spálily (v další verzi Linuxu přestal fungovat) a už nové psát nebudou (resp. píšou jen pro jednu dvě LTS verze). Pak tady máme jednotlivce, co je to baví, ale neustálé předělávání kvůli API není ta zábavná část. A pak tu máme jednotlivce, co to z nějakého důvodu skončili a nikomu se nechce opravovat cizí kód kvůli novému API.

Ve Windows to je třeba tak, že si vývojáři klidně vymyslí další verzi API a nějakou dobu udržují i ta stará. Pak můžu do Windows 11 nainstalovat ovladač 13 let staré GPU, který je určen pro Windows 10 (novější ovladač není), což je o 6 let starší OS. Podobně šly ovladače GPU instalovat staré do novějších Windows i v předchozích Windows po desítky let.

2. 2. 2025, 14:14 editováno autorem komentáře

Tie firmy, čo sa "spálili", tak dodávali zlé ovládače. Buď to boli uzavreté bloby, alebo nedodržiavali štandardy. Ale písali ste o ABI, zrazu píšete o API. V tom aby sa čert vyznal ...

Každopádne, wifi je dôležitá záležitosť. Niekto sa tých ovládačov ujme skôr, či neskôr.

> Tie firmy, čo sa "spálili", tak dodávali zlé ovládače. Buď to boli uzavreté bloby...

Problém je, že dneska používáte spoustu cizího IP (Intelectual Property). V desktopu a velkém tlustém notebooku to není problém, tam to jsou samostatné čipy. Ale v mobilu, SBC, tenkém notebooku apod. jsou ty čipy ale sloučené do jednoho (SoC). Tím pádem není možné udělat otevřený ovladač (je tam spoustu kódu od jiných dodavatelů, a ti si nepřejí kód zvěřejnit). A i když ho uděláte, tak vám na to nějaká standardizační organizace nedá nálepku (příklad s HDMI a AMD GPU, které tak nikdy nebudou mít vyšší režimy HDMI, dokud to nevyřeší blackbox čipem ala Intel/Apple/NVidia - nevím, jestli to tak mají v nové generaci karet, nebo stále v Linuxu plně nefungují).

>> Tím pádem není možné udělat otevřený ovladač (je tam spoustu kódu od jiných dodavatelů, a ti si nepřejí kód zvěřejnit)

To je problém výrobcov hardware. Ak nie sú schopní dodať poriadne zdrojáky, ich hw nemá čo robiť v Linuxe.

S timhle fundamentalistickym pristupem bychom porad mohli schanet po bazarech rtl8190, pripadne ti chudsi provozovat Linux pres ppp.
Pripadne, dotazeno do slabsiho extremu, absurdity jako jeste nedavno instalacka Debianu vs. Broadcom sitovka v serveru, kde nastesti nakonec zvitezil rozum nad nabozenstvim.

Ono to nie je nabozenstvo, ale zdravy rozum. Ludia sa v tomto delia do dvoch skupin: ti, ktorym taketo binarne bloby v jadre uz sposobili problemy a tych, ktorych to este len caka.

Pokial ma niekto nejaku supertajnu ficuru ktora musi byt v closed source, nech si to da do interneho firmware, ktory bezi priamo na prislusnom hardware. Tak, ako to napriklad robia Intel alebo AMD pre svoje gpu. Tam nikto nema s binarkami problem a kompatibilita ABI firmware je na vendoroch, co si zadefinuju, to maju.

Mně zas způsobil problém opensource driver, tak jsem se ještě rád vrátil k binárnímu. A firmware hardcore linuxáci odmítají, pokud se načte z disku a ne EEPROM. Tady je výhoda na Apple Silicon, že firmware se načte ještě před OS, takže Asahi Linux to má jednodušší než Nouveau.

> Nicméně v současném stavu tu máme firmy, které se na psaní ovladačů pro Linux spálily

To ide povacsinou o firmy, ktore si mysleli, ze nieco raz spravia, prehodia cez plot a to staci. Pre consumer class hardware to nestaci, a to dokonca ani vo Windows.

Apple ide dokonca opacnou cestou - nedovoluje pisat ovladace a smitec. Pre coraz vacsi rozsah hardware, bud sa pouzije standardny driver (usb), nejaka userland appka (tlaciaren, skenery), alebo jednboducho smola.

> (resp. píšou jen pro jednu dvě LTS verze)

Su take, co napisu drivery pre ich vlastny BSP a podporuju len to. Samozrejme, ze pocas celeho zivotneho cyklu tam bude praveke jadro. Lenze toto sa netyka hardware, ktory bude nejaky koncak instalovat. Zvycajne ide o embedded hardware, kde koncak ani netusi, ze je tam linux.

> Ve Windows to je třeba tak, že si vývojáři klidně vymyslí další verzi API a nějakou dobu udržují i ta stará.

Ako pre ktory subsystem. Napriklad ano, svojho casu Windows mal 3 rozlicne USB stacky. A malo to vplyv na pouzivatela, kvoli tomu dochadzalo k javom, ze pouzivatel prehodil mys alebo usb flashku medzi portami a zacalo mu to instalovat drivery a ked nemal admina (lebo korporat), tak skoncil s dlhym nosom. A boli aj take subsystemy, ako napriklad sietovy, kde kazdy rocny release Windows 10 rozbil drivery -- vid Intel a ako im to rozbijalo VLAN a teaming.

To ide povacsinou o firmy, ktore si mysleli, ze nieco raz spravia, prehodia cez plot a to staci. Pre consumer class hardware to nestaci, a to dokonca ani vo Windows.

Nevím přesně, co je consumer class HW, ani nedokážu teď přesně kvantifikovat množství ovladačů, které bylo nějak nuceně aktualizovat např. s novým minor releasem (jako 22H2). Ale spíš bych řekl, že mám podobnou zkušenost jako Ladis. Byly sem tam nějaké výjimky např. u grafických karet, případně pár let zpět začaly Windows s nějakým updatem vynucovat SHA-2 na podpisy, což bylo samozřejmě breaking (a v nejhorším si musel člověk bez update přepnout systém od developer režimu a vypnout kontrolu podpisů).
Také původní ovladače na některé staré grafické karty nepodporovaly novější WDDM. Ale jinak víceméně spousta hardware má ovladače s minimálními změnami mnoho let. Aktualizace se týkají dost často fungování ovladače s HW a bugfixů okolo, ne že by si je vynutila nějaká změna systémového rozhraní.

Apple ide dokonca opacnou cestou - nedovoluje pisat ovladace a smitec. Pre coraz vacsi rozsah hardware, bud sa pouzije standardny driver (usb), nejaka userland appka (tlaciaren, skenery), alebo jednboducho smola.

To bych neřekl, že je úplně správně. Oni pár let zpátky označili za deprecated původní, klasickou architekturu ovladačů (kext - kernel extensions). Byť ta zatím po manuálním zásahu pořád funguje.
Ovladače s architekturou DriverKit extension (dext) sice běží primárně v userspace, ale právě přes volání různých připravených API z DriverKitu se dá komunikovat s HW, incializovat ho, implementovat interrupt handlery, DMA přenosy atp. Přestože to není klasický ovladač, ale spíš takový hybrid a určitě to má v určitých situacích výkonové implikace, tak to neznamená, že by řekli - čus, žádný 3rd party hardware s vašimi ovladači nechceme - buď použijte naše drivery (jako např. USB Class Compliant Audio, HID) nebo si s tím povídejte po síti.

Jinak obecně, aby to nevyznělo špatně. Já tu teď nevolám po nějakém pevném ABI, driver API do Linuxu. Jádro existuje přes 30 let a existuje spousta dobrých důvodů, proč to tak není a beru to prostě jako fakt.
Přičemž u těch dvou další systémů zas chápu, že i tahle relativní stabilita (a zpětná kompatibilita) jim přesně pomohla dostat se tam, kde v rámci tržních podílů na desktopech dlouhodobě jsou.
Stejně jako když dám teď idealismus stranou, tak dokážu pochopit, proč pak třeba HW vendor nějaké periferie, který má na Linuxu potencionálně minoritní podíl svých zákazníků (slepice/vejce), prostě v určité fázi neudělá radši vůbec nic při představě, že by na to měl ideálně alokoval lidi na full time, co budou viset na mailing listech od všech subsystémů, upravovat a testovat jak se jejich kód chová napříč různými verzemi jádra.

2. 2. 2025, 18:05 editováno autorem komentáře

V prostředním odstavci je (možná chtěně, možná nechtěně) označený skutečný problém. Binární ABI nebo zdrojové API není problém. Problém je to relativně malé rozhraní, které umožní komunikaci se systémem.

U Microsoftu máme binární ABI. Je to super. Umožňuje napsat ovladač jednou, funguje víceméně všude a dlouho. Až se přijde na funkční chyby, výrobce je občas opraví. Podobně s bezpečnostníma chybama. Realita ... spousta 3rd party ovladačů obsahuje známé funkční i bezpečnostní chyby a můžeme si vybrat jestli provozovat děravý systém nebo nebude zařízení fungovat.

U Applu kombinaci ABI/API, kterou apple čas od času změní a firmy bez nadávání na vývojový model přepíšou ovladače protože nemají jinou možnost (S Applem se nevyjednává. Apple oznamuje změny a svět se přizpůsobuje).

Na linuxu se očekává driver ve formě zdrojového kódu, který projde review a pokud je všechno v pořádku, je zařazený do jádra. Driver může napsat víceméně kdokoli, stačí mít dokumentaci nebo být ochoten podepsat NDA. Pak ho někdo musí udržovat ve smyslu opravovat nalezené problémy nebo bezpečnostní chyby. Něco udělá maintainer. Rozhodně neplatí, že by odchodem maintainera přestaly drivery fungovat. Znamená to, že se to může stát časem.

Co se týká snadnosti psaní a správy driverů pomocí API versus ABI nebo jejich kombinace. ... Proč má Apple vlastní linuxovou divizi která píše drivery pro jejich vlastní HW a na těch testuje a ladí jeho funkčnost? Asi proto že je to rychlejší a levnější.

Co se týká ostatních firem. Není to otázka API/ABI, snadnosti nebo otevřenosti. Jen otázka peněz. Pokud to firmě nepřinese peníze, driver vám neudělá ani kdyby ho mohla naklikat ve webovém GUI. Když to peníze přinese (např. NVIDIA, AMD, INTEL). Napíše ho, klidně bude udržovat několik funkčních verzí a ještě občas dodá použitelnou dokumentaci, když už neriskuje peníze.