Vlákno názorů k článku Nvidia otevřela zdrojové kódy svého ovladače pro linuxové jádro od dustin - Pěkné je, jak hned po zveřejnění začaly chodit...

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...