sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Tento článek je překladem z anglického originálu, a proto vychází se zpožděním.
Začleňovací okno 2.6.28 je stále otevřené, takže momentálně není žádné vývojové jádro. Vizte článek níže, kde naleznete aktualizaci toho, co bylo ve vývojovém cyklu 2.6.28 začleněno.
Současné stabilní jádro 2.6 je 2.6.27.2 vydané 18. října. Obsahuje přibližně tucet důležitých oprav. Před ním bylo vydáno 2.6.27.1 obsahující jedinou opravu zakazující dynamické sledování funkcí.
Stabilní aktualizace pro jádra 2.6.25, 2.6.26 a 2.6.27 jsou v době psaní tohoto článku v procesu revidování; pravděpodobně budou vydána již v době, kdy toto budete číst.
Toto přidává podporu pro touchpad na OLPC. Ten má spoustu hezkých vlastností, z nichž žádná není povolená, protože hardware je příliš zachybovaný. Místo toho ho používáme jako normální touchpad se spoustou workaroundů, které mají řešit jeho časté křeče. Změny vlhkosti, pot, alobalové spodní prádlo, připojení do zásuvky, pití, zlé kočky, ... to všechno způsobuje, že touchpad začne šílet.
-- Andres Salomon by měl prodávat hardware
Jo, jsem nabručený. Kontrola kvality během tohoto začleňovacího okna byla naprosto nechutná. Mám pocit, že si musím stěžovat na každé přetažení [pull], které udělám, protože lidé mají pocit, že další nové varování není problém. A úplně pokaždé je to nové varování způsobeno naprosto mizerným kódem.
Mám obavu, že jakmile se objeví diskuze o bariérách a my je vložíme, budu naprosto paranoidní a bude velmi těžké vytřást ze mě potřebu dát bariéry úplně všude, a to včetně bariéry před a za každou bariéru až do nekonečna, abych se ujistil, že jsou to skutečně bariéry.
-- Hugh Dickins
V době psaní tohoto článku bylo od vydání 2.6.27 do hlavní řady jádra začleněno něco málo pod 6200 neslučovacích [non-merge] sad změn. Toto začleňovací okno by se mělo blížit ke svému konci, který bude okolo 24. října, takže již vcelku dobře vidíme, jak bude 2.6.28 vypadat. Změny viditelné pro uživatele začleněné od minulého týdne zahrnují:
Byly začleněny nové ovladače pro:
Strom ovladačů -staging byl přesunut do hlavní řady. Přináší s sebou nový příznak TAINT_CRAP a odpovídajícím způsobem poskvrněné ovladače pro:
Také byl přidán modul pro potlačování echa a ovladač, který umožňuje předávání síťových paketů po USB spojení.
Byla začleněna spousta práce na grafickém ovladači Intel i915; tato práce zahrnuje subsystém pro správu GPU paměti Správce grafického zpracování [Graphics Execution Manager, GEM] a podporu pro "IGD OpRegion", která povoluje ACPI řízení podsvícení. Vypadá to, že jaderné nastavování režimu [kernel-based mode setting] to do 2.6.28 asi nestihne, ale většina zbytku velkého přepracování grafiky je nyní začleněna.
Způsob, kterým videoovladače čekají na vertikální zatemňovací cykly [vertical blank cycles], byl změněn tak, aby se omezila přerušení - a tím i spotřeba energie.
Patche pro škálování správy paměti Rika van Riela byly už konečně začleněny. Tyto patche oddělují správu anonymních, soubory zálohovaných a zcela neodstranitelných stránek, čímž eliminují spoustu zbytečného prohledávání stránek.
Další vylepšení VM způsobuje, že systém uvolní odkládací prostor stránky poté, co je stránka načtena zpět do RAM; to efektivně zvyšuje velikost swapu, který je v systému k dispozici.
Přepsaná vmap vrstva od Nicka Piggina by měla poskytnout významné zlepšení výkonu, obzvlášť když počet CPU v systému roste.
Obrovské stránky budou nyní zahrnuty ve výpisu paměti, čímž se zjednoduší ladění aplikací, které tyto stránky používají.
Mrazák kontejnerů [container freezer] byl začleněn. Systém nyní může zmrazit všechny procesy v kontejneru (kontrolní skupině) jako celku.
Virtualizační kód KVM nese mnoho vylepšení, včetně schopnosti přiřadit PCI zařízení hostům a podporu "Tukwila" procesorů od Intelu.
Kprobes jsou nyní podporovány architekturou SuperH.
Je zde nová volba při připojování ext3 (data_err=abort), která způsobí, že operace se souborovým systémem jsou zrušeny, pokud dojde k I/O chybám. Pokud tato volba není přítomna, zůstává staré chování (pokračuje se a je zapsána stížnost do systémového logu).
Vyvažování přerušení v jádře pro 32bitové x86 systémy bylo odstraněno. Tato vlastnost byla již nějaký čas označena za zastaralou (ve prospěch vyvažování z uživatelského prostoru).
Změny viditelné jaderným vývojářům zahrnují:
Bylo začleněno mnoho patchů spojených se sledováním. Tyto zahrnují mechanismus sledovacích bodů [tracepoints], osazení vnitřního kódu plánovače, zlepšením schopnosti sledování funkcí ftrace, nové sledování zásobníků založené na ftrace, nové sledování bootu (initcall) založené na ftrace a nízkoúrovňový sledovací kód.
Prototyp sysctl funkce strategy() se změnil: byly odstraněny nepoužívané parametry name a nlen.
Podpora asynchronního I/O může být konfigurací z jádra odstraněna, což ušetří přibližně 7 kB prostoru na systémech, kde není AIO zapotřebí.
Jak bylo plánováno, device_create_drvdata() bylo přejmenováno na device_create() se stejnými parametry.
Nyní je mechanismus pro povolení a zakázání výstupu z volání pr_debug() a dev_dbg() pro každý modul zvlášť. Ovládá se přes virtuální soubor v debugfs. S touto změnou není spojen žádný soubor s dokumentací; instrukce, jak tuto vlastnost používat, lze najít v changelogu patche.
Nová dev_WARN() funkce
dev_WARN(struct device *dev, char *format, ...);
vypíše formátované varování společně s kompletním výpisem zásobníku. To umožní sbírat varování na kerneloops.org a zahrnovat je tam do hlášení.
Nová formátovací direktiva %pR umožní printk() a přátelům vypsat obsah struktur resource.
Je zde nová funkce, která má zjednodušit život autorům PCI ovladačů:
static inline void *pci_ioremap_bar(struct pci_dev *pdev, int bar);
Tato funkce remapuje celou PCI oblast I/O paměti podle argumentu bar.
Vizte příští Jaderné noviny, kde najdete shrnutí posledních dnů začleňovacího okna 2.6.28
Když se Jaderné noviny naposledy zabývaly chybou v e1000e, která poškozuje hardware, zdroj problému byl přinejmenším nejasný. Za pravděpodobného viníka byl považován problém v ovladači samotném, ale ti, kteří se ho pokoušeli vysledovat, si brzy uvědomili, že potřebují hledat i mimo ovladač. Po nějakou dobu byl zkoumán X server stejně jako mnoho dalších komponent systému. Když byl ale skutečný problém nalezen, ukázalo se, že šlo o překvapení pro všechny zúčastněné.
Vysledování občasných problémů je obtížné. Když vedou tyto problémy ke zničení hardwaru, je jejich odhalení ještě obtížnější. I ti nejvíc odhodlaní testeři se většinou leknou, když je před nimi možnost, že budou muset svůj systém poslat zpět výrobci k opravě. Úkol vyhledat tento problém tedy spadl na Intel; technici se zamkli v laboratoři s plnou krabicí karet e1000e a pustili se do dělení historie jádra půlením, aby identifikovali patch, který problém způsobil. O nějaký čas (a spoustu zničených karet) později dělící proces ukázal nepravděpodobného viníka: sledovací framework ftrace.
Vývojáři pracující na sledování obvykle investují mnoho snahy do toho, aby minimalizovali dopad svého kódu na výkonnost systému. I ten nejposlednější kousek režie běhu je pečlivě zkoumán a zlikvidován, pokud je to trochu možné. Obecným pravidlem je, že rozbití hardwaru znamená tak velkou úroveň režie, že to naprosto jasně překračuje přijatelné parametry. Vývojáři ftrace tedy, jakmile byli informováni o výsledku dělení, sami věnovali hodně snahy na to, aby zjistili, co se to děje.
Jedna z možností, které ftrace nabízí, je jednoduché sledování volání funkcí; ftrace vypíše řádku s volanou funkcí (a tím, kdo ji volá) pokaždé, když k nějakému volání dojde. Toto sledování je zajištěno použitím starobylého profilovacího mechanismu zabudovaného v gcc (a většině ostatních unixových překladačů). Když je kód překládán s volbou -pg, překladač na začátek každé funkce vloží volání mcount(). Verze mcount(), kterou poskytuje ftrace, potom vypisuje všechny relevantní informace při každém volání.
Jak bylo poznamenáno výše, vývojáři sledování se starají o režii. Na většině systémů je téměř jisté, že v daném čase nikdo nebude sledovat volání funkcí. Kdyby tedy byla mcount() volána i tak, znamenalo by to měřitelné zbrzdění systému. Programátoři ftrace tedy hledali způsob, jak tuto režii eliminovat, když jí není zapotřebí. Naivní řešení tohoto problému by mohlo vypadat nějak takto: místo vložení nepodmíněného volání mcount() přimět gcc, aby přidávalo takovýto kód:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
if (function_tracing_active)
mcount();
Jádro ale volá spoustu funkcí, takže i tato verze by znamenala znatelné zbrzdění; navíc by všemi těmi testy narostla velikost jádra. Preferovaný přístup tedy bývá jiný: patchování za běhu. Když se nepoužívá sledování funkcí, jádro přepíše všechna volání mcount() instrukcí no-op. Jak se tak stává, na současných procesorech je nicnedělání velmi optimalizovanou operací, takže režie několika no-op je téměř nulová. Když se někdo rozhodne sledování funkcí zapnout, jádro projde a patchuje všechna tato volání zpět.
Patchování za běhu může vyřešit problém s výkonností, ale samo o sobě zavádí vlastní problém. Změna kódu pod běžícím jádrem je nebezpečná záležitost; je zapotřebí extrémní opatrnosti. Je nutné dávat pozor na to, aby jádro v daném čase nespouštělo daný kód, cache procesorů musí být zneplatněny a tak dál. Kvůli bezpečnosti je nutné zastavit všechny ostatní procesory v systému a počkat, dokud není patchování dokončeno. Konečným důsledkem je, že patchování kódu je drahá záležitost.
Způsob, kterým bylo ftrace naprogramováno, znamenal, že každé odstranění volání mcount() se provedlo poté, co bylo objeveno pomocí skutečného zavolání mcount(). Nicméně, jak je zmíněno výše, patchování za běhu je velmi drahé, obzvláště pokud se dělá pro jedinou funkci. Proto ftrace vytváří seznam míst, odkud se mcount() volá, a později odstraní víc volání naráz. Tímto způsobem je cena za patchování významně redukována.
Problém nyní spočívá v tom, že mezi tím, kdy si kód všimne volání mcount() a kdy se jádro dostane k jeho odstranění, se věci mohly změnit. Bylo by velmi nešťastné, kdyby chtělo jádro odstranit volání mcount(), které by na daném místě již neexistovalo. Aby bylo naprosto jisté, že nebudou poškozena nesouvisející data, používá kód ftrace k vložení no-op operaci cpmxchg. cmpxchg atomicky testuje obsah cílové paměti oproti tomu, co volající předpokládá, že v ní najde; v případě neshody je na daném místě ponechána původní hodnota. Do paměti se no-opy zapíší jedině v případě, že je současný obsah paměti volání mcount().
To se zdá být poměrně bezpečné, ale selže to v jednom neobvyklém, nicméně důležitém případě. Jedním zjevným místem, kde může volání mcount() zmizet, jsou nahrávatelné moduly. To se samozřejmě může stát v případě, kdy je modul odstraněn, je zde ale také ještě jeden důležitý případ: jakýkoliv kód označený jako inicializační se odstraní ve chvíli, kdy je inicializace dokončena. Inicializační funkce modulu (a jakýkoliv jiný kód označený __init) tedy za sebou může zanechat přebytečný odkaz v seznamu "volání mcount(), která se mají odstranit", který si ftrace udržuje.
Poslední díl skládačky pochází z tohoto malého faktu: na 32bitových architekturách sdílí paměť vrácená vmalloc() a ioremap() stejný adresový prostor. Obě funkce vytvářejí mapování ze stejného rozsahu adres. Prostor pro nahrávatelné moduly je alokován pomocí vmalloc(), takže veškerý kód modulu je k nalezení v tomto sdíleném prostoru. Ovladač e1000e přitom používá ioremap(), aby mapoval I/O paměť adaptéru a jeho NVRAM do jaderného adresového prostoru. Konečným výsledkem je tato osudná sekvence událostí:
Modul je nahrán do systému. Součástí inicializace modulu je mnoho volání mcount(); místa, odkud tato volání pochází, se zaznamenají po pozdější patchování.
Inicializace modulu je dokončena a __init funkce modulu je odstraněna z paměti. Adresový prostor, který obsazovala, je uvolněn pro pozdější použití.
Ovladač e1000e mapuje svou I/O paměť a NVRAM do adresového prostoru nedávno používaného výše zmíněným inicializačním kódem.
Ftrace se dostane k patchování položek nashromážděných v seznamu volání mcount(). Některé z těchto "volání" jsou však ve skutečnosti I/O paměť patřící e1000e.
Vzpomeňme, že kód ftrace je při patchování velmi opatrný, používá cmpxchg, aby se vyhnul přepsání čehokoliv, co není volání mcount(). Nicméně, jak Steven Rostedt poznamenal ve svém shrnutí problému:
cmpxchg nás mohlo ve většině případů zachránit (se štěstím) - ale s ioremapovanou pamětí to byla přesně ta špatná věc, kterou udělat - výsledky cmpxchg na zařízení jsou nedefinované (a pravděpodobně vedou k zápisu).
Na konci je tedy zápis do špatného kousku I/O paměti - a zničené zařízení.
Při zpětném ohlédnutí je tato chyba rozumně jasná a pochopitelná, ale není žádné překvapení, že trvalo tak dlouho ji najít. Mělo by se poznamenat, že ve skutečnosti zde byly dvě různé chyby. Jednou z nich byl pokus ftrace zapisovat do neplatného ukazatele. Druhá byla ale stejně důležitá: ovladač e1000e by nikdy neměl nechávat svůj hardware konfigurovaný v režimu, kde ho jediný zbloudilý zápis může změnit v těžítko. Jeden nikdy neví, kde se věci mohou pokazit; hardware by nikdy neměl být ponechán v takto zranitelném stavu, pokud je možné tomu zabránit.
Dobrá zpráva je, že obě chyby byly opraveny. Hardware e1000e byl zamčen předtím, než bylo vydáno jádro 2.6.27 a aktualizace 2.6.27.1 vypíná dynamické ftrace sledování. Kód ftrace byl pro 2.6.28 významně přepsán; již nezaznamenává místa, kde se volá mcount() za běhu, již nepoužívá cmpxchg a, doufejme, obecně není schopný znovu způsobit takový chaos.
Jaderná paměť je obvykle alokována v relativně malých kouscích - obvykle jde o jedinou stránku naráz. Jak velikost alokace roste, uspokojení této alokace fyzicky spojitou pamětí se postupně ztěžuje. Většina jádra je proto napsána s ohledem na to, aby se vyhnulo velkým spojitým alokacím. Jsou ale momenty, kdy musí být velká oblast paměti virtuálně spojitá, ale ne nezbytně fyzicky spojitá. Jedním příkladem je alokace prostoru pro nahrávatelné moduly; jakýkoliv modul by měl žít v jediném spojitém adresovém rozsahu, ale nikoho nezajímá, jak je tento rozsah rozvržen ve fyzické RAM. Pro případy, jako je tento, poskytuje jádro sadu funkcí jako vmalloc() a vmap().
Funkce jako vmalloc() jsou dlouho známy tím, že je jejich použití poněkud drahé. Musí pracovat s jediným sdíleným (a omezeným) rozsahem adres a potřebují provádět změny v jaderné tabulce stránek. Změny tabulky stránek následně vyžadují vyprázdnění bufferu překladů adres [translation lookaside buffer, TLB], což je drahá operace na všech CPU. Jaderní vývojáři se tedy obecně pokoušeli vyhýbat používání těchto funkcí v částech jádra kritických pro výkon.
Nick Piggin si však všiml, že nás výkonnostní charakteristiky vmalloc() a přátel dostihly. Adresový prostor vmalloc() je uchováván ve spojovém seznamu [linked list] a chráněn globálním zámkem, který neškáluje moc dobře. Skutečná cena ale spočívá v uvolňování oblastí v tomto prostoru; následující vyprázdnění TLB se musí provést meziprocesorovým přerušením všech CPU, každé z nich poté musí zahodit svůj vlastní TLB. Lidé obvykle nekupují víc CPU, pokud pro ně nemají víc práce, která se na nich má spustit, takže systémy s více procesory budou obecně provádět více mapování a uvolňování v oblasti vmalloc(). Jak systémy rostou, bude v nich více globálních vyprazdňování TLB, každé z nich vyruší více procesorů. Jinými slovy množství práce roste úměrně k druhé mocnině počtu procesorů - což znamená, že to nakonec všechno padne.
Aby byly věci ještě horší, Nick má již dlouho sérii patchů, které mezi jinými hodně volají vmap(), aby mohly podporovat větší velikosti bloků ve vrstvě souborových systémů a cache stránek. Začlenění těchto patchů by významně zvýšilo čas, který systém stráví správou prostoru vmalloc(), což by nebyla dobrá věc. Zdá se tedy jako dobrý nápad nejprve opravit vmalloc(). Správu jaderných virtuálních alokací Nick skutečně v 2.6.28 vylepšil.
Prvním krokem je zbavit se spojového seznamu a odpovídajícího globálního zámku. Pro sledování rozsahů dostupného adresového prostoru se místo toho používá červeno-černý strom; nalezení vhodné oblasti lze nyní provést bez nutnosti procházet dlouhý seznam. Strom je stále chráněn globálním zámkem, což naznačuje potenciál pro problémy se škálovatelností. Aby se této záležitosti vyhnul, vytváří Nickův patch oddělené seznamy malých adresových rozsahů pro každé CPU, které lze alokovat a uvolnit bezzámkovým způsobem. Aby se využilo této vlastnosti, je potřeba volat nové funkce:
void *vm_map_ram(struct page **pages, unsigned int count,
int node, pgprot_t prot);
void vm_unmap_ram(const void *mem, unsigned int count);
Volání vm_map_ram() vytvoří virtuálně spojité mapování pro dané pages (stránky). S tímto mapováním spojené datové struktury budou alokovány v daném NUMA node (uzlu); paměť bude mít ochranu specifikovanou v prot. S verzí patche, která byla začleněna do 2.6.28, lze z těchto seznamů pro jednotlivá CPU vytvořit mapování až 64 stránek.
Všimněte si, že tyto funkce nealokují paměť, pouze vytvoří virtuální mapování pro danou sadu stránek. Jsou náhradou pro vmap() a vunmap(), ne pro vmalloc() a vfree(). Je pravděpodobně možné přepsat vmalloc(), aby tento mechanismus používal, ale to se nestalo. Volání vmalloc() tedy stále potřebuje získání globálního zámku.
V této sadě je použit další trik, který využívají všechny jaderné funkce správy virtuálních adres. Nick si uvědomil, že není skutečně nutné vyprázdnit TLB v systému okamžitě poté, co je uvolněn rozsah adres. Vzhledem k tomu, že tyto adresy jsou systému vraceny zpět, žádný kód je poté nebude používat, takže nezáleží na tom, jestli TLB v procesoru obsahuje jejich neplatné mapování. Ve skutečnosti záleží pouze na tom, aby byla TLB pročištěna předtím, než se tyto adresy použijí někde jinde. Je tedy možné nechat odmapované oblasti hromadit a poté je všechny vyprázdnit jednou operací. To významně snižuje počet vyprazdňování TLB.
O kolik rychleji věci běží? Nickovy patche (začleněnou verzi lze nalézt zde) obsahují nějaké výsledky benchmarků. V umělém testu zaměřeném na předvedení rozdílu běží nový kód 25× rychleji. Změnou kódu vmap() v souborovém systému XFS tak, aby používal vm_map_ram(), byly některé zátěže zrychleny dvacetkrát. Zdá se tedy, že to funguje.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Dekuji moc za clanek,
opet kvalitni pocteni (tedy ne, ze bych vetsinu technicky pobral:) ale clovek ma pocit , ze mu dali kounout tam kam se nikdy nema sanci dostat.
Souhlas, zvlášť o e1000e to byla hotová detektivka. 
+1
25.11.2008 19:04
grubber | skóre: 6
| blog: grubber
| Břeclav / Brno
Zrovna jsem říkal to samé přítelkyni
Jo, taky jsem to četl se zatajeným dechem. Jenom mi běhá mráz po zádech, když si představím ty maníky od Intelu, klobouk dolů.
A taky mi celé to povídání tak nějak připomnělo, jak to asi vypadalo v dobách, kdy ještě převládali opravdoví programátoři nad pojídači koláčů...
...ham... 
již nezaznamenává místa, kde se volá mcall()mcount()
Tato vlastnost byla již nějaký čas označena za zastaralou (ve prospěch vyvažování z uživatelského prostoru).To by mě zajímalo proč? Kdo jiný než jádro by měl vědět, jak jsou mezi procesory rozdělena přerušení a tudíž i jak je vyrovnat
A ještě jeden překlep: "není skutečné nutné" - má být s"kutečně".
A ako dopadla utilita na opravu kariet? Spomínam si, že vývojári Intelu na nej pracovali..
Ftrace je implicitne zapnuty, nebo ne?
Taky nejdriv jedna opravicka: "Stabilní aktualizace ... jsou V době psaní tohoto článku"
Zaujala me uprava "Další vylepšení VM způsobuje, že systém uvolní odkládací prostor stránky poté, co je stránka načtena zpět do RAM; to efektivně zvyšuje velikost swapu, který je v systému k dispozici."
Neni to zbytecne/skoda? Nesla by naopak takova stranka pouzit spis pro rychlejsi odswapovani, kdy se nebude muset cekat na jeji opetovne ulozeni? Samozrejme v pripade, ze se na ni nezapise – v takovem pripade je zahozeni neplatne kopie na disku pochopitelne.
Ono by se tezko zjistovalo, jestli se na stranku zapisuje nebo ne. A preventivni vkladani moc dlouho nepouzivanych stranek do swapu tusim existuje (takze v pripade odswapovani se stranka jen zneplatni).
Tezko? Neslouzi prave k tomu priznak Dirty v Page Extension Fields?
vertikální zatemněné cykly
zatemňovací
Nová formátovací direktiva %pR umožní printk() a přátelům vypsat obsah struktur resource.
... printk() a podobné ... nebo ... printk() a obdobné ...
25.11.2008 19:27
progdan | skóre: 34
| blog: Archař
| Teplice/Brno
Asi jeste dlouho me neprestane udivovat komplikovanost jadra a to, jak se v tom kluci muzou jeste vyznat
PS: noflame, vim ze ten kod je prehlednej a podobne, ale i tak 