Vlákno názorů k článku Nvidia otevřela zdrojové kódy svého ovladače pro linuxové jádro od oss - Vyvstli mi niekto tu posadnutost otvorenymi kodmi?

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? :-)