Názory k článku Nvidia otevřela zdrojové kódy svého ovladače pro linuxové jádro

Toho, jak chyby "nemaji" sanci do kernelu projit jsme svedky s kazdym releasem ;-) Opak je pravdou, prochazi pomerne casto... a koncime u toho, ze changelog je plny revertu.

mike@lion:~/work/git/kernel-upstream> git log --oneline --no-merges v5.16..v5.17 | wc -l
13038
mike@lion:~/work/git/kernel-upstream> git log --oneline --no-merges --grep Revert v5.16..v5.17 | wc -l
109

Changelog "plný revertů" bych si představoval trochu jinak - a bylo by zajímavé se podívat i na to, kolik z těch revertů jsou reverty commitů z téhož cyklu, tj. reverty něčeho, co se nestihlo dostat do žádného release.

Ja se ale nebavim jen o reveretech mezi major verzemi.... ale o tom, co se deje v ramci minor verzi (aneb udelejte si ten prehled mezi 5.17(.0) a 5.17.7, nebo jeste lepe v longerm mezi 5.15(.0) a 5.15.39 ci 5.10(.0) a 5.10.115) .

A jasne, budete-li si hrat na procenta v pomeru k celkovemu poctu commitu mozna hodi mozna male cislo - ale pricinou toho revertu nezridkakdy byva prave skutecnost, ze dany commit neco realne proste rozbije - tzn. ze neco (z pohledu koncoveho uzivatele) nefunguje, protoze to "kvalitni" vyvojar nedomyslel. A rec tu byla o kvalitnim kodu v kernelu, ze... ne, to neni kvalitni prace. Aneb vyvoj jede na kvantitu (pocet commitu), nikoliv na kvalitu...

Žádné minor verze jádra neexistují, to je zcela oddělená aktivita, kam se backportují vybrané důležité fixy (no, bejvávalo) a mezi nimi jsou samozřejmě i nějaké reverty. Jen pořád nechápu tu vaši posedlost reverty... každý fix opravuje nějakou chybu, v čem je revert tak zásadně odlišný od normální opravy? Stejně tak je absurdní představa některých lidí, že se (ne)kvalita kódu dá poměřovat počtem oprav (ve vašem případě dokonce jen revertů) v changelogu. Jako kdyby snad to, že projekt chyby neopravuje (nebo opravy pořádně neoznačuje) měl mít automaticky kvalitnější kód.

Neni pravdou, ze kazdy fix opravuje chybu... ono obcas ta snaha o opravu chybu spise zanasi. Revert je znamkou nedostatecneho testovani - tedy spise zadneho testovani. A to, ze se kod zkompiluje jeste neznamena, ze funguje.

Opravdu si myslíš, že vývojář může testovat na všech možných HW? Jeho kód se ostatním zainteresovaným dostane obvykle tak, že správce commit (obvykle celou sérii) po ručním a automatizovaném review (přičemž ruční dělá obvykle více lidí a automatizované testy běží v různých firmách a institucích, např. Intel jich má hodně) začlení do své devel větve a z ní si to ostatní stáhnou. Když narazí na problém, commitne se oprava. Pokud se oprava před uzavřením akceptačního okna nestíhá, nezbývá než revertovat, protože historii sdíleného repozitáře logicky nelze měnit. Je to normální vývoj.

Zrovna nedávno jsem narazil přesně na tuto situaci. Změny v USB gadget f_uac2 běžely na OTG USB řadiči dwc2 (RPi, starší ARMy), ale házely chybu na dwc3 (Intel Atom, nové ARMy). Důvod byl ten, že ovladač dwc3 spouštěl danou metodu API gadgetu asynchronně, zatímco dwc2 synchronně. O asynchronním spouštění metody vývojář změn testující na dwc2 nevěděl a vizuální review neměl šanci chybu odhalit. Většina vývojářů navrhovala revert, ale v daném případě autor stihl opravu na poslední chvíli. Kdyby ne, následoval by revert a feature by se přidal do dalšího RC. Prostě normální vývoj.

Ja treba nedavno narazil na commit, co nemohl na danem chipsetu fungovat za zadnych okolnosti. A dana zmena se tykala primo ovladace daneho chipsetu, nikoliv nejake genericke komponenty. A ano, pokud se nekdo vrta v ovladaci, mel by byt schopen otestovat, ze jim provedena zmena nezpusobi deadlock celeho systemu pred tim, nez zmenu pushne - takze nestaci, kdyz se mu to jen zkompiluje.

Nevím, kolik máš commitů v jádře. Já moc ne, max. pár desítek, ale všechny do jednoho byla docela starost protlačit, běžně tři i více verzí (první verze samozřejmě po akceptaci řešení na mailinglistu), než byli správci a automatické testy spokojeni. Ano, k revertům dochází, z mé zkušenosti nejčastěji proto, že po začlenění do devel větve správce a až poté jejich testováním ostatními "stakeholdery" se přišlo na problém (často i na jiném HW, s jiným chováním) a v rámci akceptačního okna daného releasu by se již nestihlo problém zanešený commitem opravit.

Aneb vyvoj jede na kvantitu (pocet commitu), nikoliv na kvalitu...

Nechápu, na základě čeho jsi u kernelu k tomuto došel. Samozřejmě je tlak na minimální velikost commitu, aby jeden neřešil více, než je nezbytně nutné. I z malé změny pak vznikne hodně commitů, což je ale naprosto správně.

Naopak z mé zkušenosti se každá změna posuzuje, zda je nutná. Nejde až tak o out-of-tree zdrojáky, ale o backportovatelnost změn do starších LTS jader, což je vždy pěkná pakárna.

Ano, nejaky "long term support" vyvojare jen obtezuje, to vime :-) Jenze pro bezne nasazeni (ve smyslu koncovych zarizeni, uzivatelu) je to nezbytna vec. Predstava vyvojaru, ze lidi (v praxi) budou provozovat kod z "main" branch je sama o sobe zcestna.
A vidite, mit "stabilnejsi" ABI by pomohlo i v udrzbe tech LTS jader.

===
A vidite, mit "stabilnejsi" ABI by pomohlo i v udrzbe tech LTS jader.
===

Tak možná prvních pár let, pak by všem z toho bordelu v kódu hráblo :-)

Kod kernelu je pry kvalitni... tak o jakemze bordelu tu je rec? :D

Bordel, který by postupně vznikl, kdyby nebylo možné měnit API mezi moduly při změnách a přidávání nových featur.

Ono kdyby psani novych featur predchazela seriozni analyza, tak ten vyvoj vypada jinak. Ale requirements engineering je vec, ktera se moc nenosi, ze ;-) Lepsi je rovnou chrlit kod a za pochodu zjistovat, co mi kde jeste chybi.

Možná by to jaderným vývojářům šlo líp, kdybys jim poradil, jak to mají dělat správně.

Nekdo zahledeny do sveho ega a vlastni dokonalosti (aka "ja produkuji bezvadny kod, ostatni pisou sr**ky) vas poslouchat rozhodne nebude ;-)

No kecat dokaze kazdy... ale ked im to predvediete, ako sa to robi, to bude uz ine. Budte prikladom.

Ja ale nejsem vyvojar. Ja jsem clovek, co se s vyrobnimy zmetky vyvojaru, ktere se tu prezentuji jako udajne kvalitni kod nasledne musi vyporadat v beznem kazdodennim provozu...

1. - To chce realne cisla, lebo u bezpecnostnych chyb sa toto nedeje.
2. - Beriem
3. - V realite malokedy.
4. - To by som si bez cisiel tiez neodvolil tvrdit.
5. Na to je dokumentacia.

5. rozdil mezi dokumentaci a kodem je v tom, ze kod ma pravdu

Aktualni dokumentace, to je takovy oxymoron :-)

Ano, ABI mezi moduly není stabilní, celý kernel se bere jako jeden projekt. Považuji to za správné rozhodnutí, které umožňuje dlouhodobě držet kvalitu kódu.

Samozřejmě ABI do userspacu stabilní je a co jsem měl možnost vidět, jeho stabilita se bere vážně.

Caste zmeny ABI jsou spise znamkou nekvalitniho navrhu. A ono prosadit nove veci do kernelu taky neni vzdy jednoduche (protoze rozhoduje mj. i politika) - veci pak nucene zustavaji mimo kernel. I na takovy wireguard jsme od roku 2016 cekali... az na rok 2020.

Hovoríme tu o internom ABI; nie o verejnom (syscalloch). Pri zmene interného ABI sa aktualizujú aj jeho používatelia. Pokiaľ nejaký externý produkt používa interné ABI, ide do rizika, ktoré si musí riešiť sám.

Ti se ale aktualizuji jen v pripade, ze je dany kod zaclenen do kernelu. Coz ale neni ve vsech pripadech (a duvody nezacleneni jsou ruzne). Pouziti interniho ABI muze mit ruzne duvody - treba uz jen skutecnost, ze v tom verejnem dany call neni ani dostupny - zvlast u pokrocilejsich veci to nemusi byt az tak neobvykle.
Jiste - z pohledu kerneloveho vyvojare to neni jeho problem. Ale koncovou obeti je nakonec uzivatel. Ale to vyvojare netrapi, ze? ;-) Pritom vedle se pak divime, ze lidi pouzivaji zastarale verze software a odmitaji aktualizovat... inu prave treba proto, ze kernelovy vyvojar zmeni interni ABI, s novou verzi znefunkcni ten nezacleneny modul... ktery ale dany uzivatel z nejakeho duvodu potrebuje. Proste ty "divoke" zmeny (byt interniho) ABI pachaji vice skody nez uzitku.

Stabilní ABI v Linuxu není a nebude, je to i záměr.(*) Ale je třeba ve Windows, aby mohly existovat binární ovladače.

(*) ABI se zachovává třeba v enterprise distribucích (RHEL) právě kvůli externím ovladačům od třetích stran

Trápit by to především mělo výrobce HW s out-of-tree ovladači. Je otázkou, proč jsou mimo hlavní větev. Důvodů bývá více, ale bohužel velice často je jím nízká kvalita kódu a míra integrace se stávajícími službami kernelu, takže jej správce daného subsystému odmítne začlenit.

Nestabilní interní ABI je feature kernelu a nemá smysl si tu na to stěžovat.

Zatimco kod kernelu je vysoce kvalitni :-) A proto se v changelogu najde (ve stabilnich vetvich) mj. spousta revertu... kdy nekdo s nejakym "hura stylem" zaclenenym patchem... ehm... nedomyslel souvislosti. Jo, tyhlety reci o (ne)kvalitnim kodu... ono i tady plati, ze co vyvojar, to nazor na (ne)kvalitu. Ono je to dost subjektivni, ze...

> Důvodů bývá více, ale bohužel velice často je jím nízká kvalita kódu a míra integrace se stávajícími službami kernelu, takže jej správce daného subsystému odmítne začlenit.

Jaký má být správný postup, když vyrobíte PCIe kartu pro ovládání urychlovače, který je jeden na světě? To se má taky mainlinovat?

Například speciální USB zařízení se vyřešila drivery v userspace (libusb). Ale pro jiné use-cases, jako „data acquisition pomocí DMA z PCIe“, takový mechanismus AFAIK neexistuje,

Jaký má být správný postup, když vyrobíte PCIe kartu pro ovládání urychlovače, který je jeden na světě? To se má taky mainlinovat?

Že by se v provozních nákladech takového urychlovače nenašly drobné pro aktualizaci zdrojáku driveru na novou verzi jádra, pokud již ke změně interního API došlo? Navíc jak často se jádro takového řídícího PC upgraduje?

Pro PCI karty podporující MSI a šechny PCIe je v standardním jádře dobrá podpora driverů v userspace

https://docs.kernel.org/driver-api/uio-howto.html#generic-pci-uio-driver

DMA jak na PCIe tak na FPGA lze řešit přes obecný udmabuf. Ten je mimo jádro a asi se do něj jen tak nedostane

https://github.com/ikwzm/udmabuf

Když bude vybraná naše přednáška o CAN (FD)

https://pretalx.installfest.cz/installfest-2022/talk/review/RHYCE9Y7HRRNT9HFEXNYNHR8EHGYRZ7Z

a související Workshop na Installfest, tak si můžete na Zynqu zkusit Eltvor Logický analyzátor https://github.com/eltvor/zlogan/ napojený na naše CTU CAN FD core, OpenCores SJA1000 a XCAN, který k ukládání RLE změnových vzorků UDMABUF používá.

Jinak k stabilitě API a ABI, před 30 lety nedozrála doba na IO Uring a podobné a tato vnější ABI vyžadují i změny v myšlení v jaderném prostoru.

Obdivuji Dave Cutlera za návrh Windows NT driver ABI stabilního 30 let, je to úplně jiná liga než z komerčních příčin dodnes udržované Win API z dob 16-bit Windows, ale myslím, že právě tvrdé interní ABI je jedním z hlavních důvodů, proč moderní paradigmata WIndows nezvládají a i samotný Microsoft musí networking v Azure řešit údržbou vlastní GNU/Linuxové distribuce.

Trápit by to především mělo výrobce HW s out-of-tree ovladači.

Tady je potřeba především rozlišovat mezi closed source o open source out of tree drivery. A proto také mezi kernelovým ABI a API, což se tady v diskusi vesele míchá dohromady. (Na druhou stranu, stabilní není záměrně ani jedno.)

Myslím, že v tomto případě je to víceméně jedno, protože se diskuse týká out-of-tree ovladačů, ke kterým zdrojáky jsou, ale je potřeba je při změnách v kernelu aktualizovat (tedy API). Osobně v tom nevidím až takový problém - je to správa SW jako každého jiného. Mám starý projekt v legacy javě a při přechodu na javu > 8 se taky musí trochu upravit, to je normální.

se diskuse týká out-of-tree ovladačů, ke kterým zdrojáky jsou, ale je potřeba je při změnách v kernelu aktualizovat (tedy API)

Právě na to jsem upozorňoval, protože tady skoro všichni pořád mluví o změnách ABI, ale pokud nejde zároveň o zpětně nekompatibilní změnu API, open source out of tree driverů se to nedotkne. Typický příklad je třeba přidání nového prvku doprostřed struktury: open source out of tree driver se prostě jen znovu přeloží, closed source to potenciálně rozbije.

> Ti se ale aktualizuji jen v pripade, ze je dany kod zaclenen do kernelu.

Áno. Presne to je pointa **interného** ABI.

> Coz ale neni ve vsech pripadech (a duvody nezacleneni jsou ruzne).

Čo je v poriadku. Prečo si však niekto myslí, že *jeho* dôvody na nezačlenenie sú lepšie ako dôvody, ktoré viedli k rozhodnutiu neudržiavať stabilné interné ABI?

> Pouziti interniho ABI muze mit ruzne duvody - treba uz jen skutecnost, ze v tom verejnem dany call neni ani dostupny - zvlast u pokrocilejsich veci to nemusi byt az tak neobvykle.

To je v poriadku. Cena za to je známa.

> Ale koncovou obeti je nakonec uzivatel. Ale to vyvojare netrapi, ze?

To by malo trápiť v prvom rade autorov modulov, ktoré používajú interné API a nie sú ochotní ich začleniť do jadra. Prečo by vývojári jadra mali za nich robiť maintenance?

> Pritom vedle se pak divime, ze lidi pouzivaji zastarale verze software a odmitaji aktualizovat..

Bežný používateľský software toho nemá moc spoločné s interným ABI jadra. Bežný používateľský software používa syscally, ktoré stabilné sú. Dôvody neupgradovania bývajú často niekde inde, napríklad v tom, že nové verzie sú v niektorých ohľadoch z pohľadu používateľa v niektorých ohľadoch horšie.

A to Linux je jediný systém, ktorý má stabilné ABI na úrovni syscallov. Iné systémy to nemajú, stabilné ABI je až na úrovni symbolov zdieľaných knižníc. Jadro NT bolo známe tým, že čísla syscallov sa generovali pri kompilácií a každý build to mal inak.

> inu prave treba proto, ze kernelovy vyvojar zmeni interni ABI, s novou verzi znefunkcni ten nezacleneny modul... ktery ale dany uzivatel z nejakeho duvodu potrebuje.

Pokiaľ aplikácia vyžaduje kernelový modul a tento modul je nezačleniteľný do jadra, niečo je veľmi, veľmi zle s danou aplikáciou. (Medzi veľmi, veľmi zle s aplikáciou počítam aj Virtualbox, kde moduly boli veľmi nízkej kvality. Tie ktoré sa podarilo dokopať do nejakej formy už začlenené sú, zvyšok si udržuje svoju nízku latku).

> Proste ty "divoke" zmeny (byt interniho) ABI pachaji vice skody nez uzitku.

Linuxu to napríklad pomohlo vyhnúť sa problému, ktorý mal Windows: jeden čas mal Windows 3 rozličné USB stacky. Preto sa stávalo, že pri prehodení zariadenia z jedného do druhého portu sa preinštaloval ovládač -- systém musel totiž rozhodnúť, v ktorom porte je aké zariadenie, aký je k nemu ovládač a ktorý USB stack ten ovládač potrebuje. Trvalo roky, než sa Windows tohto problému zbavil.

Linuxoví vývojári toto robiť nebudú, obzvlášť nie pre nekooperatívnych výrobcov.

Modelovych situaci, ktere v praxi muzou nastat tu uz par jmenovano bylo. Nektere duvody "nezacleneni" jsou ryze politicke/pravni, nikoliv technicke (priklad napr. zminovaneho ZFS, technicky rozhodne nejde o nekvalitni kod). A hezky jste popsal arogantni pristup vyvojaru, ktere vubec netrapi potreby beznych uzivatelu - ale hlavne uspokoji sve vlastni ego a jsou presvedceni o vlastni dokonalosti :-) .

> priklad napr. zminovaneho ZFS, technicky rozhodne nejde o nekvalitni kod

Tak keď sa Oracle rozhodol, že ZFS bude pod licenciou úmyselne nekompatibilnou s GPL, kto sme my, aby sme spochybňovali ich rozhodnutie? Tak je licencované tak ako je, keď chce niekto vyplakávať, nech ide vyplakávať k Oraclu.

> A hezky jste popsal arogantni pristup vyvojaru, ktere vubec netrapi potreby beznych uzivatelu - ale hlavne uspokoji sve vlastni ego a jsou presvedceni o vlastni dokonalosti :-)

Nie je to o vlastnej dokonalosti, ale o vynaloženej práci. Keď ja spravím koninu a musím ju po sebe opraviť, tak si za to môžem sám a nabudúce si dám pozor. Keď hlúposti robí niekto iný a ja by som to mal po ňom opravovať, tak 1) kde je moja motivácia, aby som to robil ja? 2) kde je motivácia pre pôvodcu problému, aby ho viackrát nerobil? Aktuálny prístup zodpovedá obe otázky.

Tak keď sa Oracle rozhodol, že ZFS bude pod licenciou úmyselne nekompatibilnou s GPL

Abychom byli fér, k tomu se nerozhodl Oracle ale Sun. Oracle (poté, co Sun koupil) se pouze rozhodl to tak nechat.

To ZFS je dost nešťastný příklad. Tam je důvodem licence, nikoliv politika. A začlenění kódu do jádra by už jen znamenalo vyčkávat na soudní tahanice s Oraclem.

Ale to je ta politika. Kdyby kernelove ABI nebylo nestabilni (a to je politicke rozhodnuti), neni ani problem se ZFS. Ale kernelovym vyvojarum proste chybi ohleduplnost k vecem okolo nich, vyhovuje jim ta anarchie. Oni dobre vedi, ze jsou veci mimo oficialni kernel - ale proste se na hulvata tvari, ze to neni jejich problem, kdyz se rano spatne vyspi a vsechno rozvrtaji...

Přesně tak, není to jejich problém.

Ne, je to problem nas vsech :-) Vysledkem je prostedi, kde se v koncovych zarizenich "radsi" pouzivaji stare uz neudrzovane kernely. A ty jsou zdrojem dalsich problemu...
A ne, bezny koncovy spotrebitel nebude resit to, ze out-of-tree vyvojar je lempl, co svuj ovladac nechce prepsat do noveho kernelu. Ale my pak resime to, ze ty levne krabicky se starym kernelem, co si domu nakoupi utoci na vsecko kolem sebe...

Kdyby kernelove ABI nebylo nestabilni (a to je politicke rozhodnuti)

Není to politické rozhodnutí, je to rozhodnutí, které má jasné praktické důvody a vzhledem k modelu a rychlosti vývoje linuxového jádra by to v podstatě jinak ani nešlo. Zkuste se zeptat někoho z distribučních kernelových vývojářů, jaký neskutečný opruz je vymýšlení krkolomných kABI hacků při backportech security fixů do starších distribučních jader.

Ak to ale beriete ako jeden produkt, tak potom ten argument pada, lebo je jedno, ci je to otvorene alebo nie. Pretoze vyvojari zdrojaky mat budu.

WTF?

uzivatel s nickem OSS se pta na vyhody otevreneho SW? :-)