Linux 2026-os „tavaszi nagytakarítás”: kódmaradványok eltüntetése egészen a Linux v0.1-ig visszamenően

enlightened Ez az oldal a közösségért készül. heart Kövess minket máshol is:  Linux Mint Magyar Közösség a Mastodon-on  Telegram csatorna – csak hírek  Beszélgessünk a Telegram – Linux csevegő csoport  Hírek olvasása RSS segítségével  Linux Mint Hivatalos Magyar Közösség a Facebook-on      Linux Mint Baráti Kör a Facebook-on
wink Ha hasznosnak találod, és szeretnéd, hogy folytatódjon, támogasd a munkát Ko-fi vagy Paypal segítségével. laugh

kami911 képe

Gleixner ma közzétett egy nagyszabású, a teljes forrásfát érintő takarítást, amely a LATCH, a CLOCK_TICK_RATE és a get_cycles() körüli kód „[ab]use” jellegű használatokat veszi célba. Gleixner elmagyarázta, miért maradtak ezek a kevéssé emlegetett, elavult kódmaradványok a Linux kernel részei:

"1) LATCH

A LATCH definíció egészen a Linux 0.1-es verziójáig nyúlik vissza, és egészen a mai napig fennmaradt – teljesen rossz okokból.

Kezdetben az x86 PIT frekvenciájára épült, és az időméréshez kapcsolódó átváltásokat is ez irányította.

Amikor megjelentek a nem x86 architektúrák, a LATCH-ot úgy módosították, hogy a CLOCK_TICK_RATE-re épüljön. Ezzel elkerülték, hogy hozzá kelljen nyúlni azokhoz a központi részekhez, amelyek a LATCH-ra támaszkodtak.

Mindez több mint két évtizede értelmét vesztette, amikor a timerek, az időmérés és az ütemezés infrastruktúráját újraírták.

Ennek ellenére maradt egy magányos túlélő az arch/x86/kernel/apm_32.c fájlban, amely a Linux 1.3.46-ig (1995. december) nyúlik vissza.

Ez vezet a következő történelmi „gyöngyszemhez”.

2) CLOCK_TICK_RATE

Amikor a Linux túllépett az i386-on, a LATCH-ot „rugalmasabbá” tették azzal, hogy a CLOCK_TICK_RATE-re alapozták. Így más frekvenciákhoz is lehetett igazodni, nem csak az i386 PIT frekvenciájához.

Ahogy a LATCH, ez is régen értelmét vesztette. Mégis, pusztán „szórakoztató értéke” miatt, minden ok nélkül átmásolták később érkező új architektúrákba is – ráadásul olyan megjegyzésekkel, amelyek szerint amúgy semmi értelme.

És persze itt is volt egy magányos túlélő az arch/x86/kernel/setup.c fájlban, annak ellenére, hogy nagyon régóta csak a PIT_TICK_RATE egyik aliasa.

3) get_cycles()

Ezt a 2.1.133pre4-ben (1998. december) vezették be, hogy kihasználják az akkoriban vadonatúj TSC-t. A bevezetés mindent tönkretett, kivéve az i386 SMP-t olyan CPU-val, amelyben volt TSC, majd néhány napon belül kijavították üres stubokkal, amelyek 0-t adtak vissza, illetve CONFIG_TSC-hez kötött #ifdef-es trükközéssel a 2.2.0 release előtt.

Szórakoztató, hogy az elnevezés tudatosan figyelmen kívül hagyta: a TSC a Time Stamp Counter rövidítése, nem pedig Cycle Counter. Ehelyett arra a véletlen egybeesésre építettek, hogy a TSC ugyanazon a fix frekvencián futott, mint a CPU magja.

Ez akkor vált érdekessé, amikor a CPU-k megkapták a frekvenciaskálázást: a TSC ekkor változó frekvenciájú véletlenszám-generátorrá alakult.

Egy évtizeddel később a CPU-tervezők észhez tértek, és a TSC-t invariánssá tették: jellemzően a névleges CPU-frekvencián fut, ami lehetővé tette, hogy megbízható időmérésre használják.

A nem x86 architektúrák a get_cycles() megvalósítását arra a folyamatosan futó számlálóra alapozták, amely épp elérhető volt a CPU-jukban. Némelyik valódi CPU-ciklusszámláló volt, de sok fix frekvencián futott, amelynek semmi köze nem volt a CPU-ciklusokhoz.

2004/2005 körül az időmérési alrendszert teljesen újraírták, és generikussá tették az ütemezési órával és más kapcsolódó infrastruktúrával együtt. Ezzel az átírással a get_cycles() nagyrészt elavulttá vált, de hiába szerepelt sok ember teendőlistáján, sosem tűnt el. Inkább kényelmi eszközként szolgált, hogy más dolgokat – például a random_get_entropy() friss hozzáadását – rá lehessen építeni, egy ocsmány #ifdef/#define makrólabirintuson keresztül.

A többi megmaradt felhasználási eset többnyire debugging és tesztkód. Különösen a teljesítménytesztekben való használat legjobb esetben is módfelet vicces. Miközben a get_cycles() név azt sugallja, hogy hozzáférést ad a CPU-ciklusokhoz, a valóság az, hogy a legtöbb rendszeren csak egy nem specifikált számlálót ad. Sok architektúrán egyszerűen 0-t ad vissza, mert vagy nincs ilyen számlálójuk, vagy nem is vették a fáradságot, hogy implementálják.

Valójában a get_cycles()-t már régen át kellett volna nevezni get_bogo_cycles()-ra, összhangban a BogoMIPS „nyűgözd le a barátaidat” printk-kel, amely szintén csak történelmi „szórakoztató értéke” miatt létezik még.

De az igazi megoldás az, hogy az egészet eltávolítjuk, ahelyett hogy tovább terjesztenénk ezt a kétes értékűséget."

Ennek megfelelően a nagy patch-sorozat eltávolítja a Linux kernel LATCH és CLOCK_TICK_RATE elemeit, miközben más kódrészeket is egységesít és kitakarít, köztük a get_cycles() körüli részeket. A get_cycles() csak néhány CPU-architektúrán marad meg, kizárólag architektúrán belüli implementációs részletként.

A nagyszabású takarító patch-sorozat itt található: a kernel levelezőlistán.