Kernel napló - mi hozza (3) infrastruktúra c t magazin

Trendek és hírek | Kernel napló

Az AppArmor, az on-access víruskeresők belépési pontjai, egy újonnan írt Out of Memory Killer és az Xen-Dom0 kód alapjai a Linux 2.6.36-os rendszermag legfontosabb újításai. Némi szerkezetátalakításnak köszönhetően ez a verzió egy kicsit kisebb lesz, mint elődje, annak ellenére, hogy több százezer sornyi új kód található.

Szerda reggel Linus Torvalds kiadta a Linux 2.6.36 kiadás előtti, hatodik verzióját. Jelezte, hogy hamarosan szeretné kiadni a 2.6.36-os verziót, de talán beilleszt egy másik előzetes verziót.

A rendszermag-napló ezt a lehetőségként veszi igénybe, hogy folytassa a "Mit hoz a 2.6.36" minisorozatot az olyan új funkciók ismertetésével, mint például a memóriakezelés, a rendszerépítés, valamint a különféle CPU- és rendszerarchitektúrák támogatása. A sorozat első része a grafikus hardver változásával foglalkozott, a második a fájlrendszerekkel, a tárolókkal és a hálózati hardverekkel; az ACPI, a PCI, az energiagazdálkodás és az USB, FireWire, V4L/DVB és Co. illesztőprogramok változásairól szóló negyedik rész néhány napon belül elkészíti a mini sorozatot.

Biztonság

Miután az AppArmor fejlesztői, amelyeket a Novell 2006-ban közölt, évek óta sikertelenül próbálták belefoglalni a biztonsági fejlesztés kernelkódját, ennek a 2.6.36-os verziója végül megtalálta a kernelt (beleértve az 1, 2, 3, dokumentációt). A SELinuxhoz hasonlóan az AppArmor az alkalmazásokat meghatározott műveletekre korlátozhatja; Azok a támadók, akik biztonsági résen keresztül jutnak hozzá a rendszerhez, például a szerverszoftverben, ezért csak korlátozott kárt okozhatnak.

Az AppArmor híres arról, hogy könnyebben adminisztrálható, mint a SELinux. Ez utóbbit a Red Hat támogatja, és többek között a Red Hat Enterprise Linux (RHEL) és a Fedora használja. A Novell sokáig az AppArmor-ra koncentrált, de 2007-ben elszakadt saját AppArmor fejlesztési osztályától, és 2008 óta használja a SELinuxot is. Ennek eredményeként az AppArmor fejlesztése jelentősen lelassult, amíg John Johansen új lendületet adott az év elején, és végül a hivatalos kernelbe való felvételét szorgalmazta. Johansen korábban a Novellnél dolgozott, és jelenleg felelős az AppArmor integrálásáért a Canonical Ubuntuban.

A TALPA-ból előkerült Fanotify-nak számos próbálkozásra volt szüksége, és néhány évvel azelőtt, hogy Torvalds integrálta volna (többek között 1, 2, 3). A 2.6.31-be integrált Fsnotify-ra épít, és belépési pontokat kínál, amelyeken keresztül például a víruskeresők csatlakozhatnak a fájlok ellenőrzéséhez, amikor a tartalom megjelenése előtt hozzáférnek a rosszindulatú programokhoz ("on-access scan"). Számos LWN.net cikk (köztük 1, 2, 3) tartalmaz néhány háttérinformációt a Fanotify működéséről, valamint a Fanotify korábbi verzióinak problémáiról.

[Frissítés 2010. október 14., 9:30] Csak néhány nappal a Linux 2.6.36 befejezése előtt a fejlesztők ideiglenesen deaktiválták a Fanotify felhasználói terület interfészeit annak érdekében, hogy orvosolni tudjanak néhány hiányosságot, amelyek közül néhány az ABI-t is érinti (1, 2, 3) - ez azt jelenti, hogy a Fanotify egyelőre nem használható. A felhasználói tér interfészeinek hibakeresését és újbóli aktiválását tervezik a 2.6.37-es kernelben; Még mindig nem világos, hogy ezek a javítások esetleg a 2.6.36 sorozat egyik stabil kernjébe is eljutnak-e. [/Frissítés]

Memória és szálkezelés

A kernel fejlesztői jelentősen megváltoztatták és nagyrészt átírták az Out of Memory (OOM) gyilkost, amely megöli a folyamatokat, ha nincs elegendő memória, hogy a rendszer folytathassa a munkát (1, 2, 3). Ezen változtatások miatt az OOM finombeállítása a/proc /

/ oom_adj most "elavult", és 2012 augusztusában el kell tűnnie. Az LWN.net további háttérinformációkat tartalmaz az OOM változásairól az "Újabb OOM gyilkos átírása" cikkben.

A rendszermag-hackerek integrálták a "Concurrencey Managed Workqueue" -eket is, amelyek optimalizálják a kernelszálak (beleértve az 1-et, a dokumentációt) kezelését. Ennek eredményeként a rendszermagnak hatékonyabban kell felhasználnia az erőforrásokat, jobban kell méreteznie és kevesebb szálral kell kijönnie sok rendszeren - a felhasználók ezt is észreveszik, mert ez lerövidíti a ps -A által kiadott kernelszálak listáját. A fejlesztő a javítások további elõnyeit és okait a javítások részletes levelében és a Git-Pull kérés részeként közli; Az LWN.net tavaly ősszel cikket írt a Concurrencey Managed Workqueues témáról.

[pagebreak virtualizáció, Kbuild]

Építészeti kód

A kernel által támogatott processzorarchitektúrák listája ismét növekszik a 2.6.36-mal, és mostantól a Tilera által kifejlesztett 32 bites TILEPro és TILE64 processzorokat is tartalmazza (beleértve 1, 2, 3). MIPS-szerű VLIW processzorok, sok maggal, amelyek iMesh hálózaton keresztül kommunikálnak egymással. Mivel meglehetősen gazdaságosak, több mint 10 000 processzormag helyezhető el egy szerver állványon. Az Nvidia Tegra processzorainak támogatása, amelyek az ARM architektúrán alapulnak (beleértve 1, 2, 3), az Android környezetből származnak. Ezenkívül a kern a Ben NanoNote illesztőprogramjainak (köztük 1, 2, 3, 4, 5, 6, 7, 8) mintegy 90 százalékát tartalmazza - nyitott hardveres platformot tartalmazó zsebszámítógép, amely tavasz óta Európában is elérhető elérhető.

Avi Kivity karbantartó, Avi Kivity Git-Pull kérésében azt írja, hogy a 2.6.36-os verzióban nincsenek fontosabb újdonságok a KVM-ben. Ugyanakkor jelez néhány teljesítmény-optimalizálást, és megemlíti az Xsave (1, 2) és az AVX (Intel Advanced Vector Extension) parancsok támogatását a vendégrendszerekben.

Jeremy Fitzhardinge és Konrad Rzeszutek Wilk Git-Pull kérései áttekintést nyújtanak a Xen-kód változásairól. Az előbbiek által gyűjtött javításokkal a Paravirt illesztőprogramok most már teljesen virtualizált tartományokban is használhatók ("pv-on-hvm"); A többi változás azt jelenti, hogy a Linux mint paravirtualizált vendégrendszer egyfajta virtuális IOMMU-n keresztül férhet hozzá a PCI-eszközökhöz, amelyet a gazdagép (Dom0) biztosít (beleértve az 1-et is). A változtatások egy része megalapozza azokat a kódokat, amelyeken a Linux kernel "kezdeti tartományként" működtetésére szolgáló kódot kell alapozni - egyfajta lecsupaszított Dom0 támogatással. Ezt a kódot jelenleg az LKML tárgyalja, és a következő verziók egyikében átkerülhet a Linux fő fejlesztési ágába.

Sovány

A Kbuild kód most négy új célt kínál:

Az "oldnoconfig" helyettesíti a "loose_nonint_oldconfig" szót, és a ".config" rendszermag konfigurációs fájl összes konfigurációs beállítását "nem" értékre állítja, amelyeket korábban nem állítottak be.
A "listnewconfig" helyettesíti a "nonint_oldconfig" szót, és felsorolja az összes beállítást, amelyet még nem állított be a ".config".
Az "alldefconfig" létrehoz egy ".config" fájlt, amelyben az összes beállítás megadja a Kconfig fájlok által alapértelmezettként megadott beállításokat.
A "savedefconfig" egy "defconfig" nevű konfigurációs fájlt ír, amelyben csak azok a beállítások vannak felsorolva, amelyek eltérnek a Kconfig fájlok szokásos beállításaitól.

Ez utóbbiak célzása segítségével a fejlesztők több tucat szabványos konfigurációs fájlt készítettek a Linux rendszermag által támogatott különféle rendszer- és processzorarchitektúrákhoz, amelyek felváltják a korábbi szabványos konfigurációs fájlokat. Mivel ez utóbbi korábban tartalmazta az összes opció bejegyzését, amelyet alapértelmezésként a kernf kconfig fájljaiban határoztak meg, a megfelelő elkötelezettség majdnem 6 MB és több mint kétszázezer sort távolít el a kernelforrásokból.

Az Itanium (IA64) és a Power támogatási rendszergazdái korábban ilyen módon egyszerűsítették konfigurációs fájljaikat (1, 2). Mindezek a változások a fő oka annak, hogy a 2.6.36-os forráskódnak valamivel kisebbnek kell lennie, mint közvetlen elődje - ez rendkívül szokatlan, mert az utóbbi években a kern minden új verzióval több százezer sorral nőtt.

A normál konfigurációs fájlok étrendje már a 2.6.35-gyel kezdődött, amikor a kernel fejlesztői karcsúbbá tették az ARM rendszerek fájljait. Az egész nem változtat semmit a felhasználó számára, mert a korábbiakhoz hasonlóan a "make defconfig" létrehoz egy alapvető konfigurációs fájlt a saját rendszered számára.

[pagebreak különféle, apró gyöngyök]

különféle

A rendszermag-hackerek tovább csökkentették a Big Kernel Lock (BKL) használatát az infrastruktúra-kódban és számos illesztőprogramban - ideértve a TTY alrendszert is, ami még a legtapasztaltabb rendszermag-hackerek számára is nehézségeket okozott. A fejlesztők így közelebb kerülnek ahhoz a célhoz, hogy a rendszermag ezen a terjedelmes zárszerkezet nélküli szabványos rendszereken dolgozzon, ami rontja a méretezhetőséget és a rendszer teljesítményét.
Az x86-os kód most támogatja az Intel Sandy Bridge processzorainak teljesítménykorlát-értesítéseit, amelyek várhatóan a következő év elején várhatók (1, 2, 3). Az új Hwmonitor meghajtó, a pkgtemp, ezen alapul, és kiolvashatja a processzor hőmérsékletét (1, dokumentáció)
Bizonyos helyzetekben a folyamatütemező csökkenti a versenyt a kernelszálak között, amelyek kizárólagos irányítást szeretnének megszerezni egy elfoglalt erőforrás felett. Ez lehetővé teszi az aktív folyamat zavartalanabb működését, ami egyes esetekben jelentősen megnöveli az adatátvitelt (Commit, LWN.net cikk).
Az elődökhöz hasonlóan a 2.6.36 is számos változást hoz a hibakereső, a teljesítményfigyelő és a nyomkövető kódban. A rendszermag-hackerek eltávolították például az Ftrace plug-in kmemtrace-t, mivel a funkciók mostantól a "kmem" és a "perf kmem" típusú nyomkövetési események segítségével hajthatók végre. Amint azt a "Mit hoz 2.6.36 hoz" sorozat első része már leírta, az Intel KMS támogatással rendelkező rendszerek rendszermagja most KDB hibakereső héjat kínál az X szerver összeomlásának okának elemzésére amikor a szöveges konzolra váltás már nem lehetséges, és nincs konfigurálva soros konzol.
Szinte egy hónappal az egyesítési ablak vége után a rendszermag-hackerek változtattak a folyamatütemezőn, amelyen keresztül az ütemezőnek csökkentenie kell a maximális várakozási időt, különösen asztali rendszereken, amikor más folyamatok párhuzamosan igénylik a CPU-időt - ez jobbat ígér. Válaszsebesség, amelynek gyorsabban kell éreznie a rendszert. A változást megelőző vita és a megjegyzés megmagyarázza a hátteret, és olyan mért értékeket közöl, amelyek szerint a teszt forgatókönyvben a maximális késés majdnem megfeleződött.
A 2.6.36-os verzióval a rendszermag-hackerek meg akarják szüntetni azt a problémát, amely miatt a 2.6.35-ös és néhány korábbi kernelváltozatú rendszerek bizonyos körülmények között rendkívül lassúnak érezték magukat, vagy időnként abbahagyták a válaszadást, míg a kern nagyobb mennyiségű adatot vitt át lassú adathordozóra (pl. egy USB-meghajtó) írta (1-t is beleértve).
A Tomoyo biztonsági továbbfejlesztése most egy "Interaktív kényszerítési módot" kínál, amelyet a rendszergazdák használhatnak annak eldöntésére, hogy figyelmen kívül hagyják-e az irányelvek megsértését. A YouTube videó bemutatja működését.
Stefani Seibold megváltoztatta a 2.6.32-ben már jelentősen átdolgozott Kfifo API-t a teljesítmény javítása és egy jobb API biztosítása érdekében (beleértve 1, 2). A régi API hívások továbbra is támogatottak, az új lehetőségeket néhány példa magyarázza.
A Coccinelle a make target "coccicheck" programon keresztül hívható - egy szemantikus kódelemzésre szolgáló program, amely megkönnyítheti a programozókat a munkában, amikor a kódot újrafeldolgozzák. A lehetőségekről a kernel dokumentációja és az LWN.net oldalán tavaly tavasszal megjelent cikk nyújt részleteket.

A kis gyöngyök

Számos kisebb, de korántsem jelentéktelen változás megtalálható a következő listában, az angol változtatási fejlécekkel. Az előző szövegben szereplő számos hivatkozáshoz hasonlóan a bejegyzések is a Lit Torvalds által fenntartott Git-ág webes elülső részére mutatnak, a Kernel.org "hivatalos" rendszermag-forrásaival. Az ezeken a linkeken megjelenő kötelezettségvállalási megjegyzés és az alatt kiadott javítás rengeteg kiegészítő információt nyújt a vonatkozó változásokról.

Minden link előtt szögletes zárójelben néhány betű és szám található. A "C" jelzi a Kconfig fájlok változásával járó javításokat, amelyek tartalmazzák a súgószövegeket és a konfigurációs beállításokat, amelyek a kernel konfigurálása során a "make menuconfig", "make xconfig" és hasonló eszközökön keresztül jelennek meg. A "D" olyan javításokat jelent, amelyek megváltoztatják a dokumentáció, amely a kernel ágában található a Dokumentáció/alatt. "N" jelöli azokat a változásokat, amelyek új fájlt hoznak létre. A szám nagyjából benyomást tesz a javítás méretére: az "1" 10 és 20 KByte közötti változásokat jelent, beleértve a megjegyzéseket, egy "2" a 20-30 KByte méretű változásokat; A szám nélküli változtatások kisebbek, mint 10 KB, míg a "9" -es javítások 90 KB vagy nagyobbak.

Hibakeresés, teljesítményfigyelés és nyomkövetési kód