Új x86 architektúra karbantartók

Kernel

A Linux kernel forrásfájának "arch" könyvtára tartalmazza az összes architektúra-specifikus kódot. Nagymennyiségű kód található itt annak ellenére, hogy az évek során a fejlesztői közösség igyekezett a dolgokat annyira általánossá tenni, ahogy az csak lehetséges. A Linux kernel jelenleg 26 különböző főarchitektúrához tartalmaz támogatást. Ezek közül nem egy számos alarchitektúra támogatást tartalmaz. Ezen 26 architektúra közül az egyik az i386 (a Linux kernel eredeti architektúrája), a másik pedig az x86_64, amely az i386 arch 64 bites kiegészítéssel ellátott bátyja. A két architektúra közt nagy a hasonlóság és valahányszor az lehetséges volt, megkíséreltek kódot megosztani köztük. Ennek ellenére a két architektúra forrásfája egymástól elszeparált maradt. Egyes fejlesztők szerint az i386 és x86_64 architektúrák ilyetén való elkülönítése problémás.

Számos esetben kell olyan bugot javítani, amely mindkét architektúrát érinti. Ilyenkor a legnagyobb igyekezet ellenére is előfordulhat, hogy az egyik arch-on elmarad a javítás. Hasonlóképpen az új szolgáltatások implementálásakor előfordulhat, hogy a kódot kétszer kell hozzáadni a kernelhez. Ebből kifolyólag relatív egyszerűen lehet hibát előidézni az egyik architektúrán, miközben a fejlesztő a másikon dolgozik, nem beszélve arról, hogy feleslegesen hízlalja a kernel forráskódját a kétszer hozzáadott kód. Egyes architektúra-specifikus projekteken - például virtualizáción - dolgozó hackerek megelégelték, hogy ennyit kell dolgozniuk két ennyire szoros kapcsolatban levő forrásfán. A nyomás hatására a 2.6.15-ös kernelben a PowerPC 32 bites és 64 bites architektúráját egy egységesített architektúrába vonták össze. Általánosságban az volt a vélemény, hogy ez egy jó lépés volt. Ennek ellenére akkor hasonló összevonás az x86 variánsok közt nem történt meg.

Azonban felbukkant Thomas Gleixner és Molnár Ingo, akik készítettek egy patch-et, amely összevonja a két korábban említett architektúrát. A patch hatalmas méretű, több mint 9 MB és több mint 1 700 file-t érint. A patch úgy tűnt, hogy megoldja a fejlesztők által felvetett problémát.

Azonban Andi Kleen, az i386 és x86_64 architektúrák karbantartója ellenvéleményét fejezte ki a patch-csel kapcsolatban. Mint mondta, nem tartja jó ötletnek az egyesítést, mert így az ősi "szemetet" nem fogják tudni kiszórni. Az arch/x86_64 szerinte jóval tisztább és egyszerűbb az arch/i386-nál és jelezte, hogy szeretné ezt az állapotot megtartani. A vitában Andi legfőbb érve az volt a két architektúra elszeparáltan tartása mellett, hogy így az "öröklött" dolgokat be tudják "börtönözni" az i386 fába. Ezzel a lépéssel az a kód, amely a relatív új hardvereket támogatja, sokkal tisztábban tartható.

A szeptemberi Kernel Summit rendezvényen Andi kijelentette, hogy nem kívánja karbantartani a jövőben az i386 és x86_64 architektúrákat, ha azok összeolvasztásra kerülnek egy egységesített x86 architektúra alá. Linus-t ez valószínűleg nem hatotta meg, mert egy, a két architektúrát egyesítő patch került beolvasztásra a 2.6.24-es Linux kernelbe. Viszont úgy tűnik, hogy Andi sem gondolta meg magát, mert a git szerint a kód karbantartását Thomas Gleixner, Molnár Ingo és H. Peter Anvin vette át.

A ma megjelent 2.6.24-es kernel első kiadásra jelölt verziója nagyrészt ennek a patch-nek a hatására duzzadt fel 11 MB körüli értékre az RC-ktől megszokott 3-5 MB-os érték helyett.

Bővebben itt és itt.

( Hunger | 2007. 10. 24., sze – 18:52 )

És még hogy örülnek ennek az "okos" lépésnek a külsős kernel patch gyártók...

És persze gondoljunk a cikkben szereplő kernelfejlesztőkre, akik kifejtették, hogy mekkora problémájuk van a két arch tree párhuzamos karbantartásával. Igazságot tenni nem nagyon lehet. Hogy a lépés jó-e vagy sem, majd az idő eldönti. BTW: deja vu érzésem volt. A DragonFly BSD-ben hasonlót akartak a pc32/pc64-gyel, de Dillonnak nem tetszett.

--
trey @ gépház

valamilyen szinten figyelemmel követtem és az elején a kernel fejlesztőknek sem tetszett a dolog, mert a kész
stuffokat újra kellett irni ..., de ha egyszer rendeződik, akkot reméljük jobb lesz.

és azért ez is egy szép dolog, de vannak hátrányai is

Ingó készített egy kisebb statisztikát a BUG-ok megoszlásáról 


               -------------------------------------------------------
               |    errors  | lines of code  |    errors/KLOC
               |            |                |    (smaller is better)
 --------------|------------|----------------|------------------------
  arch/i386/          5717            73865         77.3
  arch/x86_64/        2993            31155         96.0
  arch/x86/           8504           114654         74.1
 ..............|............|................|........................
  arch/ia64/          1779            64022         27.7
  arch/mips/          2110            94692         22.2
  arch/sparc64/       1387            49253         28.1
 ..............|............|................|........................
  kernel/              762            83540          9.1
  kernel/time/          15             4191          3.5
  kernel/irq/            1             2317          0.4
  mm/                  464            46324         10.0
  net/core             176            24413          7.2
 ..............|............|................|........................

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.10-pancs1-wifi2 - 2.6.22.9 kernel madwifivel itt

( turul16 v | 2007. 10. 24., sze – 19:01 )

Lehetlesz talalni utasitast a sok macro kozott ? :)
Szerintem nem jo otlet. Egy kozos konyvtarba beszurni amit kozosen hasznlnak esetleg..

( BaT | 2007. 10. 24., sze – 19:53 )

És az nem lehetséges, hogy az x86_64 arch tisztább kódját megpróbálják átvezetni x86-ba? Vagy épp attól tisztább a kód, mert x86_64 előnyeit kihasználja?

Nem csak attól tisztább, hogy az x86_64 egységes voltát kihasználja, hanem attól is, hogy egy relatív új arch-hoz, mint az x86_64, amit 2000-ben jelentettek nyilván kevesebb workaround, trükk, kódgányolás halmozódik fel, mint az i386 processzor megjelenésétől (1986) napjainkig.

--
trey @ gépház

Ha jól értem az egésznek az a célja, hogy könnyebben karbantartható és fejleszthető legyen a kód. Attól, hogy a két kódot összeöntik, az x86_64 rész nem fogja feljavítani a másik részt. Inkább a fejlesztőnek okoz gondot, hogy több dologra kell figyelnie, biztos lesznek részek amiket könnyen megoldhatna a 64bit-es rész alatt, de trükköznie kell mert a kódnak menni-e kell a régi procikon is.

( Chain-Q v | 2007. 10. 24., sze – 20:17 )

A nyomás hatására a 2.6.15-ös kernelben a PowerPC 32 bites és 64 bites architektúráját egy egységesített architektúrába vonták össze. Általánosságban az volt a vélemény, hogy ez egy jó lépés volt.

Ja. Mi felhasznalok meg baromira orultunk. 2.6.20-ig a PowerPC support olyan instabil volt, hogy jo hogyha 2-3 napot kibirt a gep spontan reboot, kernel panic, es hasonlok nelkul. Teljesen alap G4-es egyprocis CHRP gep, OpenFirmwarevel (Pegasos II). Ennel standardabb PPC hardver keves van, es megis. A 2.6.20 lett ugy-ahogy stabil. A tamogatott lapok fele meg ment a levesbe, mivel eltavolitottak a non-cache coherent architekturak tamogatasat (AmigaOne, Pegasos I, es meg nehany mas embedded lap). Ezek azota se kerultek vissza, mondvan, senkinek nem kellenek. Ok mar csak tudjak. No komment.

Kb. ilyesmit tudott pl. egy 2.6.18 nalam (5 legmagasabb uptime). Mind fagyassal/reboottal vegzodott. 

charlie@stronghold:~$ uprecords -m 50 | grep 2.6.18 | head -5
     7     4 days, 07:21:10 | Linux 2.6.18-4-powerpc    Sat Jun  2 02:04:48 2007
     8     3 days, 11:57:12 | Linux 2.6.18-4-powerpc    Tue May 29 10:14:39 2007
    10     2 days, 07:51:05 | Linux 2.6.18-4-powerpc    Thu Jun 21 09:18:59 2007
    11     1 day , 12:59:31 | Linux 2.6.18-4-powerpc    Tue Jun 19 20:17:33 2007
    12     1 day , 11:45:17 | Linux 2.6.18-4-powerpc    Thu Jun  7 00:18:06 2007

Ugyanaz a hardver, 2.6.21.4, valamennyi szandekos reboot miatt ert veget: 

charlie@stronghold:~$ uprecords -m 50 | grep 2.6.21 | head -5
     1    40 days, 18:46:28 | Linux 2.6.21.4            Thu Jul 26 18:54:27 2007
     2    38 days, 05:34:26 | Linux 2.6.21.4            Sun Sep  9 13:39:01 2007
     3    20 days, 03:46:29 | Linux 2.6.21.4            Mon Jul  2 14:19:13 2007
     4     8 days, 04:15:13 | Linux 2.6.21.4            Sun Jun 24 10:03:40 2007
->   5     7 days, 00:38:45 | Linux 2.6.21.4            Wed Oct 17 19:36:34 2007

Remelem sikerul vmi hasonlot prezentalni x86-on is. Hatha attol nagyobb felzudulas lenne, es vegre beanyazna valaki valami odaillot. Megerdemelnek.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Az igény (mekkora?) valószínűleg kevés. Karbantartója lenne-e?

Lenne. Van egy osztrak srac, aki AmigaOne-ra barkacsolja a Linux kernelt folyamatosan, idonkent postolva kerdeseket Debian PPC meg mas kernel listakra. Valaszt sosem kap, patchjeit leszarjak, segitsegkeresei suket fulekre talalnak. Bar nem sok usert supportalna (kb. parszaz ember maximum), de igeny lenne ra. Nalam pl. porosodott sokaig egy A1, mert nem birtam Linuxszal hasznalni rendesen. Pedig akartam. De mivel nem birtam zoldagra vergodni vele, vettem egy masodik Pegasos2-t inkabb. Aztan meg annak a supportjat is szetk#?rtak honapokra a kernelben, mint azt fentebb vazoltam volt... Ja, mellesleg a regi OldWorld Macek supportja is broken volt, par verzion at, es hasznaltam - volna, mert olyan gepem is van. Szinten, a Debian PPC fejlesztoi listan (is) sikitoztak az userek, hogy nem megy ez, nem megy az, ami regebben igen. Valasz ritkan volt, es akkor sem pozitiv. (Megj: bar a Debian listakra hivatkozom tobbszor, a vanilla kernel is ugyanazokat a szimptomakat produkalta.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Gondolom olyan sok fejlesztő és tesztelő dolgozott PPC -re, és olyan sok felhasználói visszajelzés érkezett az esetleges hibákról (na meg talán a javítás mikéntjéről), hogy azzal telt meg a lista... :S

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Szvsz:
Lehetne, de épp ez az opensource rendszerek átka (linux, *bsd, stb...). Azaz sok, nem mai procival szerelt gépen futnak ilyen rendszerek. Épp azért, mert egy fizetős rendszernél, ha sokat kellene sz*pni egy régebbi archal, akkor inkább dobják annak támogatását. Viszont mivel a nyílt rendszereket sokkal többen fejlesztik, és kevésbé fontos a kiadás időpontja, van elég energia arra, hogy régebbi archokat is támogassanak.

Nevetni fogsz, de nagyon sok helyen még fel vannak használva - még ha azoki kívülről nem is számítógépnek néznek ki. Apu mesélt pl. egy Linux alpú játékgépről (kaszinók, ilyes), amiben még 486-os proci volt. Most akkor mi legyen? Szopassuk az ilyen felhasználást, vagy örüljünk, hogy a Linux idefele is terjed?

Jelenleg is kaphatók kisfogyasztású új, célgépek 586+-os AMD Geode processzorral, amiből pl. router-t, meg ilyesmit építenek, gyártanak. Célgépek, beágyazott microATX lapok, stb. Nem ritka ez, pl. az én Cisco PIX-emben is 133 MHz-es AMD SC520-as processzor dologzik. Ipari felhasználásra nem ritkák ezek a cuccok.

--
trey @ gépház

( emberk | 2007. 10. 24., sze – 23:45 )

Szerintem ezzel csak bonylultabb lesz. Majd lehet mazsolázni, hogy melyik hová tartozik 64-vagy 32. A régi felálással igaz hogy kétszer annyi munka volt, mert amit megírtak a 32-bites kódra azt meg kellett írni a 64-esre is. Na most majd lehet nekik tippelgetni, hogy ez még 32-vagy már 64-btes rész? Na majd meglátjuk.

( x15 v | 2007. 10. 25., cs – 11:20 )

Szerintem igaza van Andi Kleen-nek. Rengeteg ősrégi drivert kell kerülgetni kernel fordítás közben, amiket szerencsére kihagytak a 64 bites részből. RZ1000 és CMD64X bugos IDE vezérlők, sok SCSI, stb, stb. Sokkal jobb volt eddig ezektől külön tartani a modern cuccokat. A 64bites kernelt 2.5.99 óta használom (persze mindig frissítve ;) ), soha nem volt bajom belőle, nem kis terhelésű sql és web szervereken. Nem örülök, hogy így megkavarták. Lassan kernelt kellene megint frissíteni, nem tudom, mi legyen.....
---
/dev/sda1 has gone 49710 days without being checked, check forced.