Linux

Egy érdekes thread alakult ki az LKML-en azzal kapcsolatban, hogy Marcelo Tosatti (a jelenlegi stabil Linux kernel széria karbantartója) azt tervezi, hogy beolvasztja Andrea Arcangeli legfrissebb VM munkáját a 2.4-es kernelbe.

Mivel Marcelo nem értette pontosan, hogy milyen változtatásokat szándékozik Andrea véghezvinni, Marcelo kérte, hogy magyarázza el azokat. Többek között arra várt Tosatti magyarázatot, hogy Arcangeli miért távolította el a VM kódból az OOM killert (Out of Memory Killer - része a VM (virtuális memória) kódnak. Feladata, hogy meghatározott rendszerben "lője" ki az alkalmazásokat, ha az operációs rendszer kifut a memóriából, így visszanyerve azt a memóriát, amit a "kilőtt" alkalmazás használt).

Arcangeli szerint az OOM killer kód nem jó, szerinte az OOM killer káros például az adatbázis szerverek működésére, ezért azt eltávolította. Ebből alakult ki a hosszabb diskurzus, amelyben pro és kontra érvek hangzottak el az OOM killer-rel kapcsolatban.

A thread itt kezdődik.

"Hello,

Itt a -pre2. USB frissítést, PPC beolvasztást, m68k beolvasztást, IDE változtatásokat Alan-tól, network driver frissítéseket Jeff-től tartalmaz a többi javítás és frissítés mellett." - írta Marcelo az LKML-re pár órával ezelőtt.

Russel King (az arm architektúra karbantartója) egy patchet postázott Linusnak, amellyel (végre) Linus kernelfája lefordul arm platformon (az arm architekúra kis késésben van az i386-hoz képest. A 2.6-os kernel most került olyan állapotba, hogy lefordítható arm porcesszoron).

Egyetlen dologgal van még probléma az arm környezetben. A /proc/kcore nem működik. A /proc/kcore egy virtuális file, amely az éppen futó kernel "magját" mutatja. A /proc/kcore-t a debugger programok használják például arra, hogy az adatszerkezetekről információt nyerjenek, stb. Úgy tűnik, hogy az arm architektúrán nem egyszerű a /proc/kcore-t működésre bírni. Russel King ahelyett, hogy nagy energiát ölt volna valami ronda megoldásba, egyszerűen úgy döntött, hogy nem támogatja a /proc/kcore-t az arm-on (hacsak valaki neki nem áll, és meg nem csinálja).

Erre Linus úgy reagált, hogy megkérdezte a listán, hogy használja-e még egyáltalán valaki a /proc/kcore filet. Szerinte /proc/kcore egyike a "cool feature"-öknek, de személy szerint Ő nem nagyon használja, és amúgy is gyakran hibás a kernel infrastruktúrális frissítések után. Ezért javasolja, hogy szűnjön meg a /proc/kcore.

Az egyetlen dolog ami a kcore mellett szól, az az, hogy az Oprofiler használja néhány infó kinyerésére, de ezt az Oprofiler kisebb módosításával meg lehet változtatni. Jelenleg úgy tűnik, hogy ha valaki nem hoz fel valami nyomós indokot a kcore mellett, akkor az lassan már csak történelem lesz.

A napokban megjelent a Linux 2.6.0-test4 kernel. Lassan, de biztosan közeledünk a vadonatúj Linux rendszermag kiadásának napja felé. Elkezdődtek a találgatások, hogy vajon mennyit kell még várni ahhoz, hogy a 2.6.0-ás "stabil" kernel megjelenjen.John Cherry (OSDL) Linus Bitkeeper-beli kernelfájának fordításai (hiba/figyelmeztetés) statisztikái alapján valaki megdörzsölte a kristálygömböt, és megpróbálta megállapítani, hogy mikorra várható a nagy nap.

A jóslat e kép alapján készült. A jóslat pedig 2003. október 12-re szól.

Én nem jósok maximum összefoglalom az eddig megjelent Linux kernelek megjelenésének időpontjait:

Az első stabil kernel az 1.0-ás 1994. március 3-án jelent meg. Az 1.1-es fejlesztői kernel 1994. április 6-án. A kettő között eltelt napok száma 34 nap.

Az 1.2-es stabil kernel 1995. március 7-én jelent meg. Az 1.3-as fejlesztői kernel 1995. június 12-én. A kettő között eltelt napok száma 97 nap.

A 2.0-es stabil kernel 1996. június 9-én jelent meg. A 2.1-es fejlesztői kernel 1996. szeptember 30-án. A kettő között eltelt napok száma 113 nap.

A 2.2-es stabil kernel 1999. január 26-án jelent meg. A 2.3-as fejlesztői kernel 1999. május 11-én. A kettő között eltelt napok száma 105 nap.

A 2.4-es stabil kernel 2001. január 4-én jelent meg. A 2.5-ös fejlesztői kernel 2001. november 22-én jelent meg. A kettő között eltelt napok száma több, mint 300 nap.

Tiltakozás az europai parlament "bölcs" döntéshozói ellen.

Mint arról a múlt héten írtam Alan Cox egy évre távozik a kernelfejlesztők közül, hogy befejezze MBA tanulmányait. Alan a levelében nem tudta megmondani, hogy mi lesz az -ac kernelfával. Egy biztos, hogy az -ac fa nem fog megszűnni, maximum kicsit átalakul (nevében). Bernhard Rosenkraenzer úgy döntött, hogy nem hagyja magára az -ac sorozatot, hanem [p]ac néven folytatja Alan Cox munkáját. A [p]ac jelenése [ported]ac.

Hogy bebizonyítsa, hogy nem csak ígérget, mindjárt portolta is az legutolsó -ac patchet a 2.4.22-höz.

A folt letölthető:

http://www.arklinux.org/~bero/kernel/patch-2.4.22-pac1.bz2

A bejelentést örömmel fogadták az LKML-en.

Bejelentés itt.

Hát ez gyors volt, a 2.4.22-rc4 -hez képest semmi sem változott.

"Hi,

Néhány bosszantó dolog jött elő, így itt az -rc4."

Letölthető patch-2.4.22-rc4.bz2

Marcelo levele:List: linux-kernel

Subject: Linux 2.4.22-rc4

From: Marcelo Tosatti

Date: 2003-08-25 0:54:13

[Download message RAW]

Hi,

A few annoying things showed up, so here goes -rc4.

Summary of changes from v2.4.22-rc3 to v2.4.22-rc4

============================================

:

o Fix drivers/net/Config.in -> CONFIG_TC35815

o Changed EXTRAVERSION to -rc4

Andi Kleen:

o Fix x86-64 ia32 emulation

Paul Mackerras:

o PPC32: Make strncpy clear the unused part of the destination

o PPC32: Make sure various sections get aligned properly by the linker

Ralf Bächle:

o dep_tristate fix for CONFIG_TC35815

-

"Hi,

Itt az -rc3 néhány javítással. Az ACPI változásoknak javítaniuk kell a legtöbb ACPI-vel kapcsolatos hibát. Kérlek teszted.

Remélem, hogy ez az utolsó -rc kiadás."

A modern hardverek gyártóinak van egy nagy problémájuk. Túl sok a láb. A gyártók egyik fő problémája, és a chip gyártás egyik legköltségesebb része a belső huzalozás kivezetése, azaz a csatlakozó felület kialakítása. A chipnek egyre kisebbeknek kell lenniük, hiszen egyre több alkatrésznek kell egy lapon elférnie. A pár négyzetcentiméteres felületen egyre nehezebb ezt megvalósítani. Gondoljunk csak a mai processzorok méretére és lábainak számára. Nem ritka a 400+ lábú processzor. Ezért a hardver tervezők fontos szempontnak tartják, hogy a tervezés során egyre kevesebb legyen a kivezetések száma. Ez nem csak a processzoroknál figyelhető meg, elég ha csak a serial ATA-ra gondolunk. Ott is cél, hogy a sok pin-nel rendelkező, széles adatkábelt igénylő csatolófelületet lecseréljék. A lábcsökkentés másik célja a megszakítási vonalak (interrupt lines) eltávolítása. A (relatíve) új hardverek úgy próbálják meg eliminálni az interrupt line-okat (és közben egy újabb lépést tenni az "örökség mentes (legacy free) környezet felé") , hogy bevezetnek egy új PCI busz technológiát, az MSI-t. Az MSI (Message Signaled Interrupts) tulajdonképpen nem csinál mást, mint a megszakítás kérést (interrupt) direkt az adat buszra helyezi, mint az adat folyam részét. Az MSI-kész eszközök ebben a rendszerben úgy jelenthetik be megszakítási igényüket, hogy sajátos értékű adatot írnak egy megadott címre. Az operációs rendszer képes ezeket az írásokat elfogni (trap), és ennek megfelelően elküldeni a megszakítást.



Egy szép napon az összes eszköz képes lesz használni az MSI-t (ez az elképzelés) és akkor nem lesz szükség a továbbiakban az elkülönített megszakítási vonalakra. Az MSI relatíve új elgondolás, és a hardver támogatás is épp csak elkezdődött hozzá. A Linux kernel jelenleg még nem támogatja az MSI-t.

Tom Nguyen (Intel) egy patchen dolgozik, amelyet nem rég a z LKML-re postázott. A patch célja, hogy megvalósítsa az MSI támogatást a Linux kernelben. Az MSI működéséről, és a Linuxos implementációról bővebben az MSI-HOWTO-ban olvashatsz.

Az MSI patch egyelőre messze van attól, hogy bekerüljön a mainline kernelbe, mert elég komoly előkészítő munka kell ahhoz, hogy beolvasztható legyen. Ahhoz, hogy a 2.6-os kernel megszakításkezelő kódját átdolgozzák már nincs elegendő idő. Valószínű, hogy a korai 2.7 kernelbe fog bekerülni a patch.

A patch itt.