Gyorsabb Linux fordítást hoz egy méretes patchset

Címkék
From: Ingo Molnar @ 2022-01-02 21:57 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel
Cc: linux-arch, Andrew Morton, Peter Zijlstra, Thomas Gleixner,
	Greg Kroah-Hartman, David S. Miller, Ard Biesheuvel,
	Josh Poimboeuf, Jonathan Corbet, Al Viro

I'm pleased to announce the first public version of my new "Fast Kernel 
Headers" project that I've been working on since late 2020, which is a 
comprehensive rework of the Linux kernel's header hierarchy & header 
dependencies, with the dual goals of:

 - speeding up the kernel build (both absolute and incremental build times)

 - decoupling subsystem type & API definitions from each other

[...]

50-80%-al gyorsabb kernel fordítást ígér ez a patchset, ami a header fájlokat optimalizálásával nyer időt.

Hozzászólások

Hát nem tudom, ez szerintem Linusnak nem fog tetszeni.

meg a 3rd party kernel modul/driver fejlesztoknek se

amugy ezt 20-25 eve kellett volna meglepni, amikor masfel ora volt a kernel forditas. most egy 5 eves szerveren is lebuildeli fel perc alatt, nem nagyon izgat mar senkit az a kis speedup...

hat azert tisztabb attol nem lesz, hogy a struct-okat lecsereli ilyenre:

    DECLARE_PER_TASK(type, name);
    per_task(current, name) = val;

meg csomo inline-t kivett stb... ez inkabb ganyolasnak tunik mint tisztitasnak :)

ez meg egeszen aggaszto:

I did find a couple of semi-bugs in the kernel 
   where a specific order of headers guaranteed a particular code 
   generation outcome - and if that header order was disturbed, the kernel 
   would silently break and fail to boot ...

egyszer hivottak

Azt hittem, pont ezekre jó az inline. Csak egyszer kell lefutnia, oda beteszi a fordító, nem kell futásidőben ugrálnia, mégse hízik meg a kész bináris.

Vagy miért nem jó, ha egy egyszer hívott függvény inline?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nekem nem teljesen világos, hogy mit jelent az, hogy egyszer hívott. Egy helyről, de potenciálisan sokszor hívott, vagy a kernel teljes életciklusa alatt egyszer hívott függvényt? Mert ha utóbbi (pl. valamilyen inicializálás), akkor azért a néhány órajel ciklusért teljesen felesleges inlineolni. Előbbi esetén pedig attól függ, mit csinál az adott függvény. Ha a függvényhívás overheadje elhanyagolható a függvény futásidejéhez képest, illetve nem teljesítménykritikus code pathon van a függvényhívás, akkor valószínűleg szintén felesleges inlineolni.

Technical debt-et csökkenteni mindig jó, ez biztosítja a hosszú távú túlélést. Ezt a Linux kernel közössége jól csinálta eddig is.
Az szerintem különösen értékelendő, hogy egy ekkora kódbázison valaki nekiáll egy ekkora változtatásnak. 
Ennek már a kommunikációja is szép feladat, mert gondolom volt előre PoC, egyeztetés, hogy végül bekerüljön a nagy meló outputja.
 

Gábriel Ákos

Yesss!!! Állati jól hangzik, most nemrég hozta le a Phoronix is. Ez a másik, amit szeretek a Linuxban, hogy állandóan van fejlődés, a fejlesztők folyamatosan fejlesztenek, ha nincs mit épp fejleszteni, akkor egy meglévő kódot optimalizálnak (legutóbb NTFS driveren javítottak, a random generátor lett többszötösen gyorsabb, most a kernelfordítás lesz). Nem úgy van, mint zárt platformokon, ahol a fejlesztő egyszer kiszenvedi, hogy végre látszólag bugmentesen megy, akkor úgy vannak vele, hogy jól van, kezünket leporoljuk, hátra dőlünk, ez LTS lesz, 5-10 évig nem nyúlunk hozzá if it ain't broke, don't fix it / ought to be enough for anybody alapon, vagy csak tömeges piaci igény esetén, mikor rentábilis lesz lefejleszteni-támogatni, meg majd soha napján patchkedden. Meg az új verziókban általában tényleges technológiai, szakmai fejlődés van, és nem arról szól egy új verzió, hogy áttették Electron/Chrome-alapra, meg szebben csillognak benne a megnövelt méretű ikonok, progress bar és egérkurzoros animációk, és le vannak benne kerekítve az ablakok sarkai, meg középre van igazítva a tálca tartalma.

Ezt nem szokták érteni a Debian-Ubuntu userek, hogy nem az ő disztrójuk a világ közepe, meg a rolling és btw. I use Arch az nem csak egy reddites meme, hanem tényleges előnye van. Míg náluk nagy eljut a gép a BIOS bootos GRUB2 bootig, addigra egy Arch usernél nem csak hogy az UEFI systemd-boot vagy EFI stub boottal a kernel és/vagy initramfs villámgyors zstd-tömörítéssel már ki is bontatta magát (egy tíz éves üzleti laptopon is, rendes SSD-n, ahol nincs I/O bottleneck), és bebootolt, mire náluk a kernel betöltött, addigra nálam már az egész rendszer betöltött minimál WM-mel, gyorsabb (vagy ugyanolyan gyors) a boot, mint náluk esetleg a hibernációból feljövetel. Ugyanez frissítésnél, mikor még az apt és apt-get még egyáltalán a tárolók szinkronizálásával szüttög, addira Archon pacman-ban nem csak párhuzamosan lefrissült az összes tároló, meg leértek a csomagok szintén párhuzamos letöltéssel, hanem megint villámgyors zstd-tömörítéssel már ki is lettek bontva, megvan a telepítés, frissítés is, két szempillantás. Persze, elérnek ezek az újítások az Ubuntuba is, pl. a zstd-vel tömörített csomagok, de a 21.10-es verzióig kellett vele várni, LTS usereknek még extra fél év, debianosoknak min. 5 év, mert a zstd új, meg a gzip stabilabb, még kell mindenkinek 5-10 év haladék, és akkor még a párhuzamos csomagletöltésről nem is beszéltünk. Ez a baj a corporate szoftverrel, meg túl kötött döntéshozatallal bíró konzervatív disztrókkal, hogy inkább vállalati környezetbe meg szerverre valók, de nem annyira jól mindennapos felhasználásra, mert lassúak, rugalmatlan a döntéshozatal, nehezen adoptálnak újdonságokat. Ez főleg Nvidiánál látszik, hogy milyen lassan őrölnek a nagy céges bürokrácia, kódvalidálás, engedélyezés, mire kitolják a következő verziós zárt driverüket, addigra a kernel meg a X.org/mesa már 2-3 alverzióval előrébb jár megint, és az egész egy reménytelen versenyfutás, amiben mindig lemaradnak.

Windows userek ennél is rosszabbak, főleg az a retrós fajta, akinek a szemellenőjét levetetve nem lehet elmagyarázni, hogy miért gáz az XP. Csak azt tudják hajtogatni, hogy megy a Battlefield, meg a Fotóbolt, RGB, majd pedig legvégső érvként a mindenkinek falat kényérként kellő AutoCAD. Nem bírják megérteni, hogy ezek érdektelen dolgok a legtöbb usernek, aki egyszer megtapasztalta a Linux előnyeit (nem is a licencen spórolás, hanem az extra sebesség, modularitás, testre szabhatóság szabadsága, saját rendszer és adatok feletti nagyobb kontroll), sose fog visszaváltani Windowsra, se Macre, nem fogja érdekelni semmilyen Fotóbolt meg MS Iroda, nem fogja visszasírni a bűn lassú NTFS-t, meg a kínzóan lassú frissítéseket, lagokat, malware-eket, vírusirtózást, kényszerített online fiókot, telemetriát, registry-hackelést, kigyomlálandó reklámokat, Cortanát, stb.. Nem fogja érdekelni a hardvertámogatás se, mert eleve kis odafigyeléssel olyan hardvert fog venni, ami máris korrekten támogatott (és nem az fog számítani, hogy Ray Tracingben hoz extra 5-10 fps-t, vagy hogy a Mac M1 geekbenchben egy szálon kicsivel többet hoz), nem fog hiányozni neki semmilyen MS/Adobe szoftver, mert megtanulja kiváltani natív linuxos alternatívákkal, módosított workflow-val, játékokhoz meg végső esetben tart windowsos célgépet vagy célhardvert (játékkonzol).

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Az a helyzet, hogy a karomkodassal telebaszott kommentek altalaban kurvara fel lesznek szavazva. A kozonsegnek is tetszeni szokott az adott kontextusban. Mert altalaban addigra mar gecire nem indokolatlan, es addigra, mire kozossegunk egy tagja nagyritkan karomkodni kezd, mar sokmindenki mast is kurvara felbaszott valami.

(Ez a komment kivetel, mert ez egy eroltetett szemleltetes)

Ez ilyen, örülök, hogy tetszik. A legtöbb esetben egyébként úgy indulok neki, hogy rövid lesz, egy darab pár soros bekezdés maximum, aztán eszembe jut még ez-az, aztán néha grafomániába torkollik.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Szerintem nem rossz a srác. Ráadásul ki tudja rendesen fejteni az álláspontját. Nyilván nincs mindig mindenben igaza, de legalább szokott lenni egy olyan képe adott témáról, aminek egyes pontjait lehet vitatni, és amit lehet tovább formálni.

Másoknak tudnám javasolni inkább, hogy picit tájékozódjanak, mielőtt hülyeségeket írnak.

Látom ez többeket zavar, most visszanéztem, hogy ez a legtöbb szavazatot kapott komment az elmúlt 30 napban, én is nyomtam rá egy +1-et, hogy örüljetek. Tényleg nem értem, mert 1) akinek nem tetszik, letiltja a hozzászólásaim, vagy átugroja, 2) nem minden hozzászólásom ilyen hosszú, 3) azért 99%-ban a témába szokott vágni, és szerintem lehet benne hasznos dolog, azért is írom le. Amire nem tudok témába vágót írni, ahhoz inkább nem szoktam hozzászólni egyáltlán. Azt értem, hogy nem mindenki ért ezzel-azzal egyet, de az meg megint egyéni szocprobléma, erről szólna egy fórum, hogy különböző szempontokról írnak egy adott témát érintően.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

"Nem úgy van, mint zárt platformokon, ahol a fejlesztő egyszer kiszenvedi, hogy végre látszólag bugmentesen megy, akkor úgy vannak vele, hogy..."

Nem tudom, hogy máshol hogyan megy, de nálunk a fejlesztés része, hogy mindig keressük a lehetséges fejlődési pontokat. És ez egy belső céges alkalmazás. ;)

Ezer köszönet a zstd megemlítése miatt. Kipróbáltam.

Az egyik HW-ünkhöz a toolchain tele van mindenféle előrefordított libbel, emiatt ~700MB, és xz-vel kicsomagolni a tar-t még SSD-s gyors gépen is ~14s. Ugyanez a toolchain zstd -19 -cel "sűrítve" alig nagyobb az xz-s archívnál, és 7x (!!!) gyorsabban csomagolódik ki. Na ez már előrelépés!

Átkonvertálom a legfontosabb csomagjainkat.

Átkonvertálni szerintem nem éri meg, vagy max. azoknál az archívumoknál, amit sokat kell kibontogass, vagy ha mondjuk a fájlrendszerbe épített transzparens tömörítésre használod. Igazából a legjobb alacsony tömörítési fokozaton, már -1 beállítással is jobban tömörít, mint a gzip, igaz ekkor elmarad az xz tömörítési szintjétől jóval, de cserébe még gyorsabban csomagolódik be (vagy 100×-os sebességgel akár), és a kicsomagolási idő is rövidebb lehet (7x helyett mondjuk 8x-os). Én főleg a gyors betömörítési idő miatt használom, mert a saját időm kímélem vele, hogy az, amit az xz hosszasan csomagol, a zstd -1 pillanatok alatt tömöríti be, és előre tudom, hogy majd a kitömörítési oldalon is időt spórolok az illetékesnek (aki lehetek én is).

Függ a mérettől is, mert ha valami kisebb adatmennyiséget, forráskódot, stb. tömörítesz, pár KB/MB, ott nem olyan nagy az időbeli nyereség. De ha már ilyen gigabájtos, sok gigás, terás méretről beszélünk, ott iszonyat nagy az időspórolás. Főleg, ha sok magos, sok szálas a proci, és van egy gyors SSD, ami miatt nincs durva I/O bottleneck.

A zstd-nek az a baja, hogy túl új még, és mivel a Facebook reklámozza, azért nem bíznak benne az emberek, mindenki úgy van vele, hogy ez is valami egynyári sláger lesz, amit most hype-olnak, majd kikopik. Igazából meg nem, mert aki kipróbálja, látni fogja, hogy zseniális, és azt is elárulom, hogy a Facebooknak semmi köze nincs hozzá. Egy független fejlesztő munkája, ami a FB előtt is létezett, csak a FB megvette a zstd-t és lz4-et, meg a fejlesztőt tovább alkalmazza, hogy dolgozzon, optimalizáljon a kódon, de a tényleges szakmai fejlesztésbe nem szól bele, az épp úgy egy egyemberes projekt, ahogy előtte, csak a finanszírozása történik új keretek között. Elég sok minden támogatja már sok platformon, WinRar, 7-zip, peazip, Ark, stb. mind ki tudják már csomagolni a zst, tar.zst fájlokat, csomagok meg elérhető hozzá minden disztróhoz, BSD-khez, MacOS-re, stb.. Különböző commanderek alá is van már kicsomagoló addonja, meg a fuse archivemount is támogatja (amivel szintén be lehet drótozni a támogatását különöbző programoknak).

Az lz4 elméletileg még gyorsabb algoritmus, de még gyengébben tömörít. Nem győzöm hangsúlyozni, hogy elméletileg, mert a gyakorlatban az lz4 egy szálat tud, míg a zstd adott esetben a többszálúsággal visszaelőzi elég durván.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nálunk nem volt szabad csomagot frissíteni a bundle-ben, csak ha explicite az ügyfél kérte (mert mondjuk known vulnerablity volt valamelyik komponensben).
Oka: a bent lévő régi verzió már ,,kipóbált". Ha frissítek és e miatt lesz valami regresszió --> balfasz vagyok. Ha nem frissítek és kiderül valami sebezhetőség, szét lehet tárni a karokat és mutogatni a csúnyagonosz hekkerekre/zsidókra/kommunistákra. Hamar beléd verték, hogy az egyéni érdeked azt diktáljha, hogy ne nyúlj semmihez, ne javítsd ki, inkább ne is nézz oda.

Mint ahogy mástól átvett projektet sem szabad sikerre vinni soha. El kell sorvasztani, a régi projektgazda örökségének felgyújtása és égő hamvainak rituális lehugyozása közben látványosan bemutatni mekkora baromság volt már elkezdeni is. Aztán a megfelelő pillanatban reinkarnálni saját projektként.

Így megy ez.

Azért az első bekezdés nem ilyen egyszerű. A munkahelyen azért fizetnek, hogy olyan munkával töltsd az időt, amiért az ügyfél fizet. Az ügyfél pedig új feature-ért fizet és ahhoz tartozik garanciális javítás hiba esetén. Azért nem fizet, hogy valaki hobbiból szépítse a dolgokat. A tulaj pedig tud kitalálni feladatot, ha nincs mit csinálni. Például olyan módosításokat, amelyektől később költségcsökkenést vár. 

Az is egy nagyon téves elképzelés, hogy ha valaki ingyen, szabadidejében dolgozgat, akkor az milyen jó. Láttam több valóban ügyes és maximalista fejlesztőt éjszakánként hobbiból refaktorálgatni. Viszont ennek magas költsége is volt. Ő nem értékelte a saját szabadidejét, ami az ő baja alapból. Viszont a többiek munkaidejének jelentős része arra ment el, hogy az ő hobbijához alkalmazkodjon. Így fele annyira volt termelékeny a csapat és a tényleg kért feladatok lassabban haladtak. Időnként tényleg új hibákat is behozott a lelkes kolléga. És persze nagyon projekten minden módosított részt le is kellene rendesen teszteltetni. Fogja az automatizált teszt / élő teszt kapacitást. Esetleg üzleti logikát is ellenőriznie kell a megfelelő embereknek. Plusz marhára frusztráló a többieknek ez, különösen akkor, ha nekik még túlórázni is kell, hogy a saját feladatukat be tudják fejezni a folytonos variálás mellett. Szóval komonyabb projekteken tényleg nem úgy megy ez, hogy majd valaki elkezd világot megváltatni hobbiból, mert lehet hogy hosszú távon tényleg ad hozzá értéket, de rövidtávon meg tönkremegy a cég bele. Egyszemélyes projekteknél lehet esetleg ezzel játsznai, de ott eleve más az egész szituáció. 

Szerintem akkor is durva, hogy ismert kritikus sebezhetőséggel rendelkező komponenst nem frissítünk, de még patchelni is csak nagy durcásan patchelünk.
Nekem valami más jut eszembe erről.

Refaktorizálásra szökőévenként került sor kb.

Az, hogy az általad leírt csapatban gyenge volt a kohézió és szélsőségesen eltértek a nézőpontok, amit nem sikerült hosszútávon sem feloldani, szerintem egy másik jellegű probléma.

Nem tudom, én nem szeretek olyan kódot szállítani, amiben tudom, hogy ismert critical vulnerability van.

Nálunk a nemfrissítés elsődleges oka az volt, nehogy valami nem várt regresszió legyen. Azt hittem ezért vannak az egységtesztek meg a tesztverziók (ügyfélnek is adtunk rendszeresen tesztverziókat egyébként - nálunk és náluk is volt tesztkörnyezet plusz felrakhatta bármilyen eszközre amire ő úgy gondolta).

Ha jól csinálja a refaktorálást, akkor nem tör el vele semmit.

Ha rosszul csinálja, akkor meg szólni kell neki, hogy inkább ne nyúljon hozzá!

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Általában azzal szokott lenni a probléma, hogy nehéz meggyőződni arról, hogy nem tör el semmit. Egy legacy kódbázis teszt lefedettsége sem biztos, hogy megfelelő, ezért bármilyen nem-triviális refaktorálás előtt teszteket is kellene írni, így meg annyival több effort, hogy már nem éri meg, vagy nem jut rá elég idő.

Hát biztos cégtől is függ, nálunk ha valaki régi kódhoz nyúl, amiben nincsenek tesztek, akkor az az alap, hogy mielőtt valamit változtat, teszteket készít. Refaktorálás előtt is.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

A való életben akkor lehet refaktorálgatni, ha más éppen nem dolgozik azon a forráson. Viszont aktív fejlesztés közben (határidők), ha valaki minden éjszaka átmozgatja a metódusokat fájlon belül vagy pláne fájlok közt, esetleg még át is nevezi őket, akkor a verziókövető rendszer nem tudja azt feloldani. Gyakorlatilag újra kell írni minden módosítást, ami a valóban szükséges fejlesztésekhez kell. 

Persze amikor valaki már elég rutinos, akkor maga is rájön erre. De ehhez az kell, hogy sokat dolgozzon csapatban, ahol nem mindenkinek hozzá kell igazodnia. Újdonsült vezető fejlesztőknél szoktam ilyet látni, akik bizonyítási kényszert éreznek magukban, de még nem alakult ki az a látásmód, amivel csapatban lehet dolgozni. Nem ütköztek még eleget a managementtel, hogy megértésék az üzleti érték egy vállalkozásban keményen pénzkérdés, nem pedig magasztos elméletek követésében mérhető.

Egész Windows-os lett már ez a linux, hogy ilyen teljesítménynövelő potenciálok vannak belefejlesztve... 

robyboy

Ennek a Linux teljesítményéhez nem sok köze van, ez egy - részben - kernelfordítás-optimalizálás.

Nem tudom mennyire prio 1 meló a kernelfordítás-optimalizálás, tekintve

  • végfelhasználó ma már alig fordít kernelt (nem érinti)
  • egy AMD Threadripper 3990X 22 másodperc alatt fordítja le az 5.4-es kernelt, disztribútornak/kernelfejlesztőnek kellene futnia egy ilyenre (ha másból nem, szponzorációból)

Ettől függetlenül, foglalkozzanak ezzel is, ha van értelme.

trey @ gépház

hanem, valakinek a pincéjében? három évre előre kipengetve a szükségesnél esélyesen lényegesen több erőforrást? És baszakodni infra managementtel?

Ahelyett, hogy veszünk pont annyi erőforrást, amennyi kell a munkához, és a baszakodós időt inkább azzal töltjük, hogy kevesebb kelljen belőle?

A nyílt forrású projektek általában szponzorációban kapják a vasat, a kisebb szolgáltatóknál a Salgó-polc/rack szekrény helyet, a villanyt, a hűtést. Az üzemeltetést pedig megoldják a projekt önkéntesei stb. Vagy szponzorációban kapják a felhős erőforrásokat. Nem nagyon hallottam a 20+ év alatt, amióta ezeket a híreket követem olyat, hogy kitettek volna projektet azért, mert sokat buildeltek. Olyat hallottam még az internet hajnalán, hogy kitettek projektet mert elvitte a sávszélességet a sok letöltés, de mindig azonnal találtak másik szolgáltatót, egyetemet, amelyik belépett a kieső helyére.

Én ezt nem látom akkora problémának.

trey @ gépház

Én se látom akkora problémának egyáltalán, csak szerintem ez nem ilyen fekete, fehér. Egyrészt nem csak opensource projectek vannak, ahol ez adott esetben nem mindegy, másrészt bár valóban sok open source projekt kap vasat, helyet, netet, egy csomó meg nem kap, És ha a projekt maga kell előteremtse, akkor rohadtul nem mindegy, hogy a havi aws számlát kell bebudgetelni, vagy vasat.

Vagy ma már pl cloud erőforrást kap. Ha megnézed, a github igen jelentékeny részén egy csomó "nem elég nagy szponzort vonzani" projekt működik úgy, hogy valamelyik CI szolgáltató (néha direkt opensourceos) free tearjét használja, ezek pedig bizony jellemzően erőforrás limitesek, pl havi 1000 perc, vagy ilyesmi. Na, ezeknek például jó eséllyel nem mindegy, hogy mennyit lehet spórolni.

Mivel kuratóriumi tag vagyok nyílt forráskódú-related alapítvány témában (FSN), pontosan tudom, hogy ez hogyan megy. Nem egyszer intéztünk ilyet, tárgyaltunk feltételekről, kaptunk erőforrást T-től, kaptunk rackszekrényt, villanyt, sávot, vasat stb.

Szóval, beszélgethetünk tovább róla, csak kérdezném: neked milyen rálátásod van a témára?

trey @ gépház

Igen, eléggé sokat tett már, nem ma kezdte az ipart, és egy csomó jelentős kernelbeli fejlesztés a nevéhez fűződik. Lehet utánaolvasok egyébként ki ez, megérdemelné, akár csak egy cikket írhatna valaki róla.

Az meg senkit ne zavarjon meg, hogy látszólag a fordítási időből a végfelhasználó nem profitál, mert készen kapja a disztrókban a bináris kernelt. Pl. akinek valami drivergubanc miatt saját kernelt kell forgatni, meg a disztrók fenntartóinak is könnyebb, ha patchelni meg gyakran kell rollingnál fordítani az új verziókat, gyorsan kihozni, az nagyon nem mindegy, ha kétszer olyan gyorsan fordul le a cucc vagy nem, még ilyen 64 mag 128 szálas procinál is jelentős tétel, ha sokat fordítgat az ember. Arról nem is beszélve, hogy ergyább, 2 magos gépeken milyen nagy segítség ez, számos percet megtakarítanak vele csak egy fordításnál. Ennek szerintem most legjobban a gentoo-sok örülnek.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ez egy fejlesztői feature, aminek a fordítás gyorsulása csak hasznos mellékhatása (és ezzel lehet könnyebben eladni, hogy miért kell megcsinálni :) ). Egyébként az, hogy sokkal kevesebb lesz az egyes fordítási egységek  (1 db .c fájl + az összes behúzott header) keresztfüggősége nagyon sok szempontból előnyös, pl. könnyebb elemezni (kevesebb bug) vagy akár helyességet bizonyítani. Rust binding generálásról nem is beszélve.

Nem, ettől nem lesz windowsos. Bár sajnos vannak windowsos vonatkozásai is, sok mainstream disztró tényleg csak a csili-vili-re próbál gyúrni, meg Windowst/Mac-et utánozni, meg szükségtelenül mindenkire rátolni a bloatot és az univerzális konténerformátumokat (Snap, Flatpak. stb.). Ahogy egyre népszerűbbek a Linux disztrók, sajnos van egy ilyen negatív hatása, windowsosítják el. Hála az égnek, ezeket még ki lehet kerülni nem annyira mainstream disztró használatával, ahol nincs minden szar előtelepítve, meg a felhasználóra tolva.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Fellélegezhetnek a build szerverek. :-)

Elolvasva a teljes emailt nekem ez sokkal inkább tűnik egy karbantarthatóságot javító patchsetnek ami mellékhatásként gyorsabb fordítást eredményez. A 8 említett technikából az első 6-nak akkor is van értéke, ha nem hoz fordítási teljesítmény javulást.

Ez egy technikai lista, amit kernelhackerek olvasnak. Ez nem egy vezetői összefoglaló, hanem egy patch mellé mellékelt összefoglaló azoknak, akik nem tudnak napi 2000 LKML levelet és az azokra jövő reply-ket elolvasni.

Tehát, célszerű tömören, de érthetően leírni, hogy WTF, illetve, ha nem az a patch elődleges célja, ami a felsorolásban az első helyen szerepel, akkor azt kell az első helyre tenni, ami a fő célja. Mellette meg megjegyezni, hogy sideeffect-ként, még gyorsult a kernelpörgetés is.

trey @ gépház

Szerkesztve: 2022. 01. 05., sze – 09:51
25,288 files changed, 178,024 insertions(+), 74,720 deletions(-)

Hogyan tudnak ennyi modosítást ellenőrizni merge előtt?

(Eh, elsikkadt, bocs)

Ha valóban át akarod nézni, akkor nem számottevő a gitlabra várás, mert a 25000 sort nagyon sokáig nézegetjük, hogy jó-e (hogy cserében mennyivel kényelmesebb benne diffet nézni meg kommentelni....). Ha csak random adminisztrálgatunk, mert kell rá a GKH pöcsét, és az a lényeg, hogy minél gyorsabban villanjon fel, amit el sem olvasol, akkor lehet, hogy tényleg jobb az email meg a patch.

Kedvenc példám, hogy mennyire, khm, érdekes amit a kernel tetején csinálnak, az überkirály wireguard. Amiről ugye még Linus is megmondta, hogy überkirály, state-of-the art, és így kell ezt csinálni. Ugyan a threadből kiderült, hogy a vélemény kialakítása közben sikerült egy az egyben nem észrevenni vagy 80k sor crypto kódot, szóval kissé invalid. És ugyan nevezett cyrpto kódot azért erőst megköpködték akik valójában meg is nézték, ezzel együtt még mindig ott tartunk, hogy a wireshark state of the art, mert Linus megmondta

hat 20 eve az mplayernel egy ido utan mar en se gyoztem rendesen atnezni a napi patch-mennyiseget. es nem segitett senki. raadasul a legtobb esetben nem egy yes/no kell, hanem megirni hogy mit modositson/javitson rajta, vagy neha egyszerubb/gyorsabb megcsinalni helyette.

aztan voltak olyan nagy patchek is mint Albeu configtree-je, amirol tudtam, hogy szukseg van ra mert sok problemat orvosol, de az egesz kodot millio helyen modositgatta, lehetetlen volt rendesen atnezni es vegiggondolni a kovetkezmenyeket, megtalalni a bugokat. betoltuk, aztan honapokig ment a bugfixeles utana... akkor utolag nagyon megbantam, de ez van, neha kell kockaztatni :)

(es persze elsore az is szep elegans megoldasnak tunt, kb mint a wireguard lehetett a kernelben)

Persze hogy szoppancs, ha nem segít senki. Akkor is, ha igen. Pusztán azt szerettem volna mondani, hogy ha azon nyüsszög valaki, hogy lassú végigkattogtatni egy reviewt, mert neki literally másodpercei vannak, akkor amit csinál, az lehet hogy jó valamire, de hogy nem review, az tuti.