Mi érkezik a 2.6.26-ba? 4096 CPU támogatás, javított StackProtector, ... és végül ... kgdb

Kernel

Molnár Ingo a napokban egy kis ízelítőt adott az LKML-en abból, hogy mi várható a 2.6.26-os kernelbe x86 fronton. Az általa karbantartott linux-2.6-x86.git fához néhány nappal ezelőttig 74 fejlesztő 884 patch-et készített. Néhány dolog az érdekesebbek közül:

A mainline Linux kernel a 2.6.26-os kiadástól kezdve 4096 CPU-t fog támogatni. Ahogy Ingo írta, vannak ekkora rendszerek, és Linux fut rajtuk. Biztonsággal összefügg, hogy javításra került a StackProtector. A StackProtector változtatásai túl "tolakodóak" lettek volna a 2.6.25-be, így végül a .26-ban mutatkoznak be. Viszont ami ezeknél sokkal érdekesebb, hogy lesz végül a mainline Linux kernelben forráskód szintű debugger!

Miért olyan érdekes ez? Hát azért, mert Linus köztudottan debugger ellenes. A kgdb névre hallgató, forráskód szintű kernel debugger már régóta létezik, de sosem volt a mainline kernel része. Linus mindig ellene volt a kgdb beolvasztásának. Azonban február körül felcsillant a remény, hogy Linus enged, és mégis lesz kgdb a kernelben.

Linus 2000-ben kifejtette, hogy mi a problémája a debugger eszközökkel.

"Nem szeretem a debugger-eket. Sosem volt, lehet, hogy sosem lesz. [...] Cseppet sem hatott meg egyik, a kernel debugger-ek mellett [felhozott] érv sem. És hidd el nekem, az évek folyamán elég sokat hallottam. Alapvetően, végül mindegyiknek ugyanaz a lényege: sokkal könnyebb volna a fejlesztés, és képesek lennénk az új dolgokat gyorsabban hozzáadni [a kernelhez]. Egész őszintén, nem érdekel."

Szóval Linus teljesen elzárkózott minden kernel-beli interaktív debugger beolvasztásától (legalábbis x86-on).

Egészen addig ment ez így, amíg idén februárban Maxim Levitsky meg nem kérdezte Linus-t, hogy miért van az, hogy az x86.git fa már többször is beolvasztásra került, de a kgdb sosem bukkant fel a mainline kernel git fájában. A fejlesztő feltette a kérdést, hogy a kgdb beolvasztásra kerül vagy sem.

Linus álláspontja elmozdulni látszott a teljes elutasítástól. Résnyire nyitva hagyta az ajtót, amikor azt mondta, hogy addig nem tervez hozzányúlni, amíg az nem kerül felajánlásra külön, minden mástól elszeparáltan. A kijelentés nyomán Molnár Ingo vezetésével elindult a kgdb-light kezdeményezés. Az első bejelentés után néhány nappal a kgdb-light már a v10-es verziónál tartott. A levlista tanulsága szerint számos kernelfejlesztő lélegzetvisszafojtva várta, hogy bekerül-e végre a debugger a mainline kernelbe.

A kgdb "light" verziója rendelkezik az eredeti kgdb majd' összes képességével, azonban eltávolításra került belőle minden olyan rész, amely túl problémás lett volna, túl radikális változtatásokat jelentett volna a kernel számára. Így egy teljesen kezelhető alap került beolvasztásra, amelyet a későbbiek folyamán további szolgáltatásokkal egészíthetnek ki a fejlesztők.

Ingo korábbi kijelentése szerint ez a kgdb sorozat "zéró problémát jelent a kernel számára", mert egyetlen problémás kódrészletet, területet sem érint.

A 2.6.25-ös kernel kiadásával a "merge window" megnyílt, és az x86.git (benne a kgdb-light v16-tal) volt egyike az első dolgoknak, amely beolvasztásra került. Így történhetett meg az, hogy Linus sok-sok év után beadta a derekát és a Linux kernel x86 arch-on saját, interaktív, forrás szintű debugger-hez jutott.

Referenciák:
Merge window opens, kgdb merged
Kernel space: finally, a kernel debugger for Linux?
what's brewing in x86.git for v2.6.26
A kgdb honlapja

( bra | 2008. 04. 19., szo – 19:38 )

Hát biztos nem egy darab MySQL-t futtatnak azon a 4k processzoron. >;-)

Pár dolog, ami erről eszembe jutott:
- 1024 CPU-s Itanium cuccon futott régebben valami SuSE Linux (SGI gép), bár mintha az még 2.4-es lett volna (gondolom rendkívül hatékony volt). Hogy van akkor ez a több, mint 255 CPU 2008 január elsején? Ez valami ordas hack volt a SuSE részéről, ami ott is maradt?
- konkrétan milyen 4096 CPU-s gép lehet az, amin akárkik Linuxot használnak, és mire?
- ez lehet elvi támogatás is, kérdés, hogy a valóságban mennyire van értelme használni. Ha például egy ekkora rendszerben a kernel az erőforrásainak mondjuk 20%-át csak azzal tölti, hogy menedzselje magát, az nem éppen hatékony.
- egy 128 "szálas" CPU-val ez csak 32 CPU. Nudli.
- az nem úgy volt, hogy a Solaris a multiprocesszorkirály? :)

"- 1024 CPU-s Itanium cuccon futott régebben valami SuSE Linux (SGI gép), bár mintha az még 2.4-es lett volna (gondolom rendkívül hatékony volt). Hogy van akkor ez a több, mint 255 CPU 2008 január elsején? Ez valami ordas hack volt a SuSE részéről, ami ott is maradt?"

Biztos, hogy valami 3rd party hack volt.

"- konkrétan milyen 4096 CPU-s gép lehet az, amin akárkik Linuxot használnak, és mire?"

Ja, ráadásul "box"-ot ír, ami az én olvasatomban gépet jelent. Én önkényesen átírtam rendszerre, mert hihetetlen volt számomra, hogy egy darab gépben ennyi CPU lenne. Ha valaki rátalál, szóljon. :)

--
trey @ gépház

Azért előfordul:

"NASA’s new SGI Altix system is expected to be installed in August at the NASA Advanced Supercomputing (NAS) facility at the Ames Research Center at Moffett Field, Calif. The new system will be the first supercomputer to operate 2,048 processor cores and 4TB of memory under a single copy of Linux(R) — creating the largest Linux single system image (SSI) in the world."

Ha megvalósították, akkor tavaly augusztus óta működik.

--
trey @ gépház

( 2Geza | 2008. 04. 19., szo – 21:52 )

Linus elkepeszto aroganciaja sok eve ranyomja a belyeget a kernelfejlesztes hatekonysagara. Boldogok ezert a MS es az Apple reszvenyesei.

"Because I'm a bastard, and proud of it!" (C) Linus

Szerintem normalis linux fork nem azert nincsen, mert a linus fele irany a legjobb, hanem mert a linus fele irany _egyeduralkodo_, elveve a lehetoseget masfele iranyoktol. A kvazi ad-hoc modon valo egyeduralkodova valas klasszikus alaptulajdonsaga a nyilt fejlesztesi modellnek. Ezert nincs annyi erdemi gcc, X, vagy gnome fork sem, mert ezek egyeduralkodova valtak a sajat teruletukon. Egyszeruen nem lenne eleg fejlesztoi kapacitas ilyen forkokra, max nehany elvetemult geek merne csak kilepni a mainstreambol.

jól értem, hogy az érvelésed "azért egyeduralkodó, mert egyeduralkodó" logikát követi?

mindenkinek adott a lehetőség a forkra, a bsd világban meg is történt a dolog

és "a legjobb uralkodási forma, ha egy jó diktátor irányít, a legrosszabb, meg ha egy rossz. A probléma az, hogy minden diktátor a legjobbnak gondolja magát"

Akartam meg szerkeszteni a hozzaszolasom utolag, es pont ilyen diktatoros hasonlatatot akartam irni, hogy egy orszagban egyszerre egy diktatorra van kapacitas :)

De nem probaltam magyarazni, hogy miert vannak ilyen adhoc egyeduralkodova valasok (bar ez is erdekes), igazabol csak megallapitottam, mint tapasztalati tenyt.

Akkor még mondhatnám a grsec jelenlegi helyzetét, de való igaz, hogy több nem jut eszembe. Egyébként itt is meglátszik, hogy a 'lead developer'-téma jobb, mint a hülye "bizottság"-ok egy adott projektnél.

Másrészt meg a Linux nem elhanyagolható részét céges alkalmazottak (Ingo, GKH stb.) fejlesztik, akik nem mondhatják könnyen, hogy holnaptól tesznek az egészre.
It doesn't matter if you like my song as long as you can hear me sing

"Másrészt meg a Linux nem elhanyagolható részét céges alkalmazottak (Ingo, GKH stb.) fejlesztik, akik nem mondhatják könnyen, hogy holnaptól tesznek az egészre."

Igen, akik szemlátomást jól kijönnek Linus-szal. Vannak akik 10+ éve dolgoznak vele együtt és a barátjának nevezik. Ilyen ez. Olyan ember nincs, aki ne lenne valakinek unszimpatikus.

--
trey @ gépház

Nem tudom, te fenn vagy-e a FreeBSD-cvs levlistán, én igen, mert elfelejtettem anno leiratkozni. Ez a bizottságos biszbasz (vagy bürökratikus vízfej) szerintem nagyon hátrányos a FreeBSD fejlesztésére nézve.
It doesn't matter if you like my song as long as you can hear me sing

Hat pedig a verzioszamozassal haladnak rendesen, mar a 4.7-es verzional tartanak, egyes BSD-k tovabbra is hasznaljak. Elmeletileg nincs akadalya annak, hogy x.org-bol xfree86-ba menjen kod, csak az ellenkezo iranyba problemas, mert az xfree86-nak van egy advertising clause a licenceben. (mint a NetBSD-nek)

( asz | 2008. 04. 20., v – 08:08 )

"I'm a bastard, and proud of it!" - Linus
:)
András

( turul16 v | 2008. 04. 20., v – 08:36 )

Linus fejben futatja a kodot ?
Vagy printk-val debuggol ?
Esetleg néhány varázs gombbal ?

Kurvara erdekelen, hogy Linus hogyan vadaszik hibakra.

Hehe. Ne keverjuk ide a viccelodest, bar teny hogy Linus eseteben nehez megmondani (nekem) hogy mikor viccel.

De mondjuk abban van valami, hogy ha jobbak a fejlesztoeszkozok, pl. van debugger, akkor az ember nem annyira gondolja at a kodot, nem figyel annyira oda, majd a testing/debugging ugyis kihozza hogy hol vannak a hibak. Aztan meg nem mindig.

Pl. ha a lyukkartyas idokra gondolsz, amikor egy programhiba kijavitasa egy napig tartott (es akkor lehet hogy talaltal meg egyet, ami meg egy nap), nos, szerintem akkoriban az ember alaposan meggondolta hogy milyen programot lyukaszt a kartyara.

Ez persze nem azt jelenti hogy egyetertek azzal hogy nem kell debugger.

Gondolom a stack trace eleg neki, utana megnezi a forrasban mit qrtak el, esetleg beleir par printk-t oda. A gond akkor van, ha nagyon nehezen/ritkan reprodukalhato egy hiba, akkor lenne jo egy beepitett debugger, hogy ha veletlen elojott akkor "frissiben" feltarjuk a korulmenyeit.

A'rpi

( vomberg | 2008. 04. 20., v – 11:59 )

He-he...:-)

Önfejű ez a Linus gyerök de ha valaki kellően bizonyít, akkor annak ad a szavára... Nem egyszerű dolog ám messiásnak lenni!

Mindenesetre igazat adok neki abban, hogy a legjobb debugger az ember saját feje. Ha nem látod át rendesen a kódot, kenheted a hajadra.

( Andrei | 2008. 04. 20., v – 12:57 )

Egy kernel ala bepakolni ilyen sok processzort nagyon jo dolog programozoi szempontbol. Nagyon durvan nezve ketfele parhuzamos programozasi modell van: distributed memory es a shared memory.

A shared memory eseten a futo peldanyok ugyanazt a cimteret hasznaljak (a stack privat a heap kozos). Ez viszonylag konnyen es hatekonyan programozhato, toolokkal jobban el van latva. A hatekonysag onnan ered, hogy a processzek kozotti adatcserehey a process hataron nem kell atlepni.

A distributed memory eseten a futo peldanyok teljesen kulon processzekben leteznek (privat stack, privat heap), ami azt jelenti, hogy az adatcsere csak az operacios rendszerek segitsegevel tortenhet (tipikusan valami rendszerhivasban vegzodik a buli).

Namost az SGI az elso megkozelitesre nyomult, amikor felepitette az Origint es az Altixet. Az IBM a masodik lora tett a Blue Gene-el.

Mondani sem kell, hogy ami klassz dolog programozoi oldalrol, az hardveres es kernel szempontbol komoly kihivas. Szerintem az SGI cudar anyagi helyzetenek az volt oka, hogy ilyen draga vasat dobott piacra anelkul, hogy a fejlesztes koltsegeit teriteni tudta volna.