Megjelent a Linux 6.4-rc1
Linus Torvalds bejelentette a Linux 6.4 első kiadásra jelölt változatát.
Röviden: Linus újra kódolt, histogram git diff algoritmus promo, a kernelben sok változás van, de jelenleg jól néznek ki a dolgok
Linus szavaival:
Linus Torvalds bejelentette a Linux 6.4 első kiadásra jelölt változatát.
Röviden: Linus újra kódolt, histogram git diff algoritmus promo, a kernelben sok változás van, de jelenleg jól néznek ki a dolgok
Linus szavaival:
„Itt vagyunk, két héttel később, a beolvasztási ablak lezárult, és kint az -rc1.
A dolgok jól néznek ki. Személyesebb oldalról nézve az volt egy kicsit furcsa, hogy volt két olyan beolvasztási kérelem is, amikben én is közreműködtem.
Az ITER_UBUF frissítés Jenstől és az x86 LAM támogatás Dave Hansentől (a valóságban Kirill, de a kérelem Dave nevét tartalmazza) azt okozták, hogy az x86 felhasználói tér hozzáférés átdolgozásában lett még egy kis plusz munkám.
Ezt nem azért említem, hogy „óh, megint kódolhattam", hanem mert emiatt végre átválthattam a git diff alapértelmezett algoritmusát egy modernebbre. Ugyanis az alapértelmezett algoritmus elég hagyománykövető (ez a „Myers algoritmus”), és bár teljesen jól működik, azért van némi heurisztikát érintő javítás az újban, ami jobbá teszi a különbségek megjelenítését.
Így én mostantól a histogram algoritmust használom, ami a sor egyediségének vizsgálatánál figyelembe veszi a leghosszabb közös karakterláncot is, ugyanis néhány változás olvashatatlan masszává tud válni a sima Myers diff kimenetben. No nem mintha a histogram mindig jó lenne, de gyakran olvashatóbbak vele a dolgok.
Ez a változás nem szabadna, hogy bárki mást is érintsen, illetve ismerek olyanokat, akik valamelyik histogram algoritmust használják. Csak azért említettem meg, mert ezzel időnként előfordulhat, hogy különbség keletkezik a módosított sorok számában, így a változás statisztikában is, tehát érinti a beolvasztási kérelem kimenetét is.
Már megszoktam a kisebb különbségeket, ugyanakkor ha küldesz nekem beolvasztási kérelmeket, akkor egy kicsit könnyíthetsz rajtam azzal, hogy te is ugyanazt a diff algoritmust állítod be a kernel fádban, amit én:
git config diff.algorithm histogram
Vagy, ha mindenhol ezt szeretnéd használni, akkor add hozzá a --global kapcsolót, amivel a változás a fő git konfigurációba kerül, így az minden fádra érvényes lesz.
(Vagy egyszerűen csak szerkeszd a .gitconfig fájlokat, ez az amit én is tenni szoktam. Ám amikor valakinek azt magyarázom, „lehet, ezt szeretnéd beállítani”, akkor egyszerűbb a git config parancsra hivatkoznom.)
Ennek a beállítása egyáltalán nem követelmény, és őszintén szólva az esetek 95%-ában a diff kimenete nem is változik. De úgy gondoltam, megemlítem, hogy tudjatok róla (és talán azért, hogy minimalizáljam azon beolvasztási kérelmek számát, ahol „oké, ki kell derítenem, miért nem pontosan ugyanaz a beolvasztás utáni kimenet, mint a kérelemben”).
Ami pedig a beolvasztási ablak valós változásait illeti, a csatolt beolvasztási napló csak nagy vonalakban tartalmazza a történéseket. A változásstatisztikát újra az AMD GPU hardverleírásai uralják, amit a perf eszközkészlet követ, mivel ott az összes esemény fájl JSON lett. Huh.
Ha a fenti két nagyobb, de unalmas részt nem nézzük, akkor a dolgok megszokottnak néznek ki. Rengeteg fejlesztés mindenhol, és az, hogy mi érdekes, a változásnapló olvasóján múlik. Illesztőprogramok, architektúra frissítések, fájlrendszerek, hálózat, memóriakezelés, mindenhol van valami.
De van egy újdonság, aminek nem sikerült bekerülnie: az x86 shadow stack. A helyzet elég szerencsétlenül alakult, mert pont akkor jött, mikor x86 problémákkal foglalkoztam. Átnéztem a kódot és éppen elég fenntartásom támadt ahhoz, hogy egy nagyobb átszervezést kérjek.
Nem teszünk le a beolvasztásáról, amire akár a következő kiadásban is sor kerülhet.
Kérlek tesztelj,
Linus”
Az eredeti bejelentés és a változásnapló itt olvasható: https://lore.kernel.org/lkml/CAHk-=wiUxm-NZ1si8dXWVTTJ9n3c+1SRTC0V+Lk7hOE4bDVwJQ@mail.gmail.com/T/#u