Jaderné noviny – 26. 8. 2009

17. 9. 2009 | Jirka Bourek | Jaderné noviny | 3732×

Aktuální verze jádra: 2.6.31-rc7. Citáty týdne: Avi Kiviti, David Woodhouse, Ted Ts'o, Rik van Riel. V krátkosti: Co je vlastně ve skutečnosti přímé I/O? Kdo rozmrazí TuxOnIce? Líné pracovní fronty; Embedded x86; O_NOSTD; E-mailové konference Linux-ARM. Přímé I/O založené na stránkách. Vývojové statistiky 2.6.31. HWPOISON.

Obsah

• Aktuální verze jádra: 2.6.31-rc7
• Citáty týdne: Avi Kiviti, David Woodhouse, Ted Ts'o, Rik van Riel
• V krátkosti
  • Co je vlastně ve skutečnosti přímé I/O?
  • Kdo rozmrazí TuxOnIce?
  • Líné pracovní fronty
  • Embedded x86
  • O_NOSTD
  • E-mailové konference Linux-ARM
• Přímé I/O založené na stránkách
• Vývojové statistiky 2.6.31
• HWPOISON

Aktuální verze jádra: 2.6.31-rc7

Současné vývojové jádro je stále 2.6.31-rc7 vydané 21. srpna. Kromě několika větších (opravy OMAP GPIO/UART a změny radeon/kms) je to opravdu poměrně malé. Většina z těch 290 změněných souborů jsou v podstatě jednořádky ve 213 commitech (zkrácený log níže) a obecně jsme o kousek zkrátili seznam regresí. Zkrácený changelog je v oznámení společně s dalšími popisy změn a oblastí, které potřebují otestovat.

Současný počet nevyřešených regresí je 26 z celkových 108 nahlášených.

Citáty týdne: Avi Kiviti, David Woodhouse, Ted Ts'o, Rik van Riel

Mnoho jaderných vývojářů věří, že uživatelský prostor je vypálen do ROM a jediná věc, kterou lze změnit, je jádro. Ukazuje se, že tak to není.

-- Avi Kiviti

+       if (iommu->cap == (uint64_t)-1 && iommu->ecap == (uint64_t)-1) {
+               /* Prosazovat násilné chování vůči dnešním vývojářům BIOSu */

-- David Woodhouse

Konzistentní souborový systém nedostaneš ani s ext2. A jestli tvrdíš, že několik set řádek výstupu fsck, které budou detailně popisovat, jak je souborový systém zničen, věci nějak vylepší, tak mám pocit, že většina uživatelů s tebou souhlasit nebude.

-- Ted Ts'o

Doporučuju palici. Jestliže chceš přijít o data, můžeš si přitom aspoň užít nějakou srandu.

-- Rik van Riel

V krátkosti

Co je vlastně ve skutečnosti přímé I/O?

Linux, podobně jako mnoho operačních systémů, podporuje přímé I/O operace blokových zařízení. Ale jak přesně mají programátoři očekávat, že přímé I/O funguje? Jak poznamenává Ted Ts'o v nedávno zaslaném dokumentu, žádná skutečná specifikace toho, co je přímé I/O, není:

Není to součástí POSIXu ani SUS ani žádné jiné formální specifikace standardu. Přesný význam O_DIRECT byl historicky dojednán v neveřejných diskuzích mezi velkými firmami vyrábějícími podnikové databáze a jinými firmami vyrábějícími proprietární unixové systémy; a jeho chování bylo obecně předáváno ústně, a ne jako formální sada požadavků a specifikací.

Tedův dokument je pokusem lépe specifikovat, co se děje, když proces požaduje operaci přímého I/O. V současnosti se zaměřuje na souborový systém ext4, ale doufá se, že vývojáři souborových systémů v Linuxu dojdou ke konsenzu a bude možné dosáhnout konzistentní sémantiky pro všechny souborové systémy.

Kdo rozmrazí TuxOnIce?

TuxOnIce je implementace hibernace vytrvale existující mimo strom. Má mnoho hezkých vlastností, které ve verzi v hlavní řadě nejsou; tyto vlastnosti se nikdy nedostaly do podoby, ve které by je bylo možné začlenit. Vývojář TuxOnIce Nigel Cunningham nedávno došel k závěru, že k začlenění ani nedojde, protože relevantní lidé jsou prostě příliš zaneprázdnění. Říká:

Vzhledem k tomu, že to je doteď jediný výsledek, nevidím důvod, proč si představovat, že v nějaké brzké době dojde k nějakému pokroku.

V reakci na to nyní aktivně hledá vývojáře, kteří by se zhostili toho dostat TuxOnIce (nebo alespoň jeho části) do hlavní řady jádra. Pro potenciální zájemce dal dohromady seznam „k vyřízení“.

Líné pracovní fronty

Jaderní vývojáři mají již léta obavy z toho, že počet jaderných vláken překračuje rozumné meze; pro příklad vizte článek Příliš mnoho vláken z roku 2007. Jens Axboe si toho všiml také, když na jeho systému (skromný 64procesorový stroj) běželo 531 jaderných vláken. A rozhodl se, že čeho je moc, toho je příliš.

Jeho odpovědí je koncept líné pracovní fronty. Jak by se dalo očekávat, tento patch je rozšířením mechanismu pracovních front. „Línou“ pracovní frontu lze vytvořit voláním create_lazy_workqueue(); bude založena s jediným pracovním vláknem. Na rozdíl od jednovláknových pracovních front se ale líné pracovní fronty snaží dodržovat koncept dedikovaných pracovních vláken pro jednotlivá CPU. Kdykoliv je líné pracovní frontě vyslán požadavek, jádro ho nasměruje na vlákno běžící na CPU, které požadavek vyslalo; pokud takové neexistuje, jádro ho vytvoří. Vlákna se ukončí, pokud jsou po dostatečně dlouhou dobu nečinná.

Konečným výsledkem je snížení počtu vláken na Jensově systému na polovinu. Stále se zdá, že jich je příliš mnoho, ale toto je krok správným směrem.

Embedded x86

Thomas Gleixner začal svou sérii patchů poznámkou, že noční můra embedded zařízení konečně přichází do architektury x86. Klíčovým vývojem je zde nová sada patchů, která má podporovat novou sérii procesorů Intel „Moorestown“; tyto patche přidávají kus kódu, který se má potýkat s novými specifiky v tomto procesoru. Místo přidávání dalšího zmatku do kódu architektury x86 se Thomas rozhodl, že je čas na velký úklid.

Výsledkem je nová, globální struktura platform_setup, která má říci kódu architektury, jak nastavit současný procesor. Zahrnuje sadu ukazatelů na funkce, které obsluhují úlohy specifické pro platformu jako nalezení ROM BIOSu, nastavení obsluhy přerušení, inicializace hodin a o mnoho více; celkově je to patch složený ze 32 částí. Nová struktura je schopna obsáhnout mnoho rozdílů v inicializaci 32bitové a 64bitové architektury, nové architektury „Moorestown“ a stejně tak různých virtualizovaných variant. Také ji lze konfigurovat za běhu, takže jediné jádro by mělo být schopno efektivně běžet na kterémkoliv z podporovaných systémů.

O_NOSTD

Dlouhodobá unixová praxe diktuje, aby byly aplikace spuštěny s tím, že standardní vstup, výstup a chybový výstup jsou na popisovačích souboru 0, 1 a 2. Předpoklad, že jsou tyto popisovače souboru správně nastavené, je mezi vývojáři tak silně zakořeněný, že většinu z nich nikdy nenapadne je zkontrolovat. Když je tedy aplikace spuštěna a některý z těchto popisovačů je uzavřen, mohou se dít zajímavé věci.

Vezměme například program, který je spuštěn s uzavřeným popisovačem 2. Další soubor, který aplikace otevře, bude přiřazen na tento popisovač. Pokud se poté stane něco, kvůli čemu program začne zapisovat na to, co považuje za standardní chybový výstup, data budou ve skutečnosti zapsána do souboru, který tím pravděpodobně bude zničen. Škodící uživatel tak může snadno napáchat škody; pokud uvážíme setuid programy, potenciální důsledky jsou horší.

Je několik způsobů, jak se pádu do této pasti vyhnout. Aplikace se může při startu ujistit, že jsou první tři popisovače souboru otevřené. Nebo může kontrolovat popisovač vrácený voláním open() a použitím dup() ho změnit, pokud je potřeba. Tyto volby jsou ale drahé, obzvláště když uvážíme, že ve většině případů jsou standardní popisovače souborů nastaveny tak, jak mají být.

Eric Blake navrhl novou alternativu v podobě příznaku O_NOSTD. Sémantika je jednoduchá: Pokud je volání open() předán tento příznak, jádro nevrátí žádný ze „standardních“ popisovačů souboru. Pokud bude patch začleněn (a proti tomu se nezdá být žádná opozice), vývojáři aplikací budou moci příznak použít k tomu, aby se vyhnuli překvapením bez dodatečných nákladů za běhu.

Je zde samozřejmě cena v podobě nestandardního příznaku, který nebude podporován na všech platformách. Skoro by se dalo dohadovat, že by bylo lepší přidat specifický příznak pro případy, kdy je požadován rozsah popisovačů [0..2]. To by ale byla přinejmenším významná změna ABI; rozhodně tedy ne nápad, který by se dočkal dobrého přijetí.

E-mailové konference Linux-ARM

Russel King oznámil, že e-mailové konference zabývající se architekturou ARM arm.linux.kernel.org budou okamžitě uzavřeny. Zdá se, že není šťastný z kritiky, kterou obdržel na fungování těchto konferencí. Konference se tedy budou stěhovat, i když není zcela jasné kam. David Woodhouse vytvořil nové konference na infradead; zdá se, že přestěhoval i seznam členů. Je zde také snaha přesunout provoz na vger, ale možnost zachovat celou sadu konferencí a jejich členů naznačuje, že používat se budou konference na infradead.

Přímé I/O založené na stránkách

„Adresový prostor“ je v jaderném žargonu mapování mezi rozsahem adres a jejich reprezentací na souborovém systému nebo zařízení pod nimi. Existuje adresový prostor spojený s každým otevřeným souborem; jakýkoliv adresový prostor může nebo nemusí být spojen s oblastí virtuální paměti ve virtuálním (paměťovém) adresovém prostoru. U typického procesu bude existovat několik adresových prostorů pro mapování spuštěného souboru, souborů, které má proces otevřené, a rozsahů anonymní uživatelské paměti (které jako svoje záložní úložiště používají swap). Je několik způsobů, kterými může proces se svými adresovými prostory pracovat, jedním z těch neobvyklejších je přímé I/O. Nová série patchů od Jense Axboe se snaží trochu racionalizovat cestu přímého I/O a tím ji zároveň udělat trochu flexibilnější.

Motivace přímého I/O je taková, aby se datové bloky mohly přesouvat přímo mezi úložným zařízením a pamětí v uživatelském prostoru bez průchodu přes cache stránek. Vývojáři používají přímé I/O z jednoho z těchto (nebo z obou) důvodů: (1) věří, že jsou schopni řídit cachování obsahu souboru lépe než jádro, nebo (2) se chtějí vyhnout zaplavení cache daty, která se pravděpodobně v blízké budoucnosti nebudou používat. Je to relativně zřídka používaná vlastnost, která se často kombinuje s další obskurní schopností jádra: s asynchronním I/O. Zdaleka největší zákazníci této schopnosti jsou velké systémy pro relační databáze, takže není moc překvapivé, že v této oblasti pracuje vývojář v současnosti zaměstnaný u Oracle.

Když jádro potřebuje něco udělat s adresovým prostorem, obvykle se podívá na s ním spojenou strukturu address_space_operations a najde v ní odpovídající funkci. Normální soubory jsou tedy například řešeny funkcemi:

int (*writepage)(struct page *page, struct writeback_control *wbc);
int (*readpage)(struct file *filp, struct page *page);

Stejně jako většina nízkoúrovňových na paměť orientovaných jaderných funkcí i tyto funkce pracují se strukturami page. Když je paměť spravována na této úrovni, není v podstatě potřeba řešit, jestli je to paměť jádra nebo uživatelského prostoru nebo jestli je v oblasti horní paměti. Všechno je to prostě jenom paměť. Funkce, která řeší přímé I/O, však vypadá trochu jinak:

ssize_t (*direct_IO)(int rw, struct kiocb *iocb, const struct iovec *iov,
                     loff_t offset, unsigned long nr_segs);

Použití struktury kiocb ukazuje předpoklad, že přímé I/O bude předáno cestou asynchronního I/O. Kromě toho struktura iovec, ukazující na buffery, které mají být přeneseny, pochází přímo z uživatelského prostoru a obsahuje adresy v uživatelském prostoru. To následně implikuje, že funkce direct_IO() musí sama řešit přístup k bufferům v uživatelském prostoru. Tento úkol je typicky řešen v obecném kódu vrstvy VFS, ale zde je další problém: Funkci direct_IO() nelze volat pro jadernou paměť.

Jádro samo obvykle nepotřebuje používat cesty přímého I/O, ale jedna výjimka zde je: ovladač smyčky [loopback]. Tento ovladač umožňuje připojit běžný soubor jako kdyby to bylo blokové zařízení; to je nanejvýš užitečné pro přístup k obrazům souborového systému uloženým do souboru. Na druhou stranu soubory připojené pomocí smyčky mohou být snadno v cache stránek reprezentovány dvakrát: jednou na každé straně připojení. Důsledkem je plýtvání pamětí, kterou by pravděpodobně bylo možné použít lépe.

Sečteno a podtrženo, bylo by hezké změnit rozhraní direct_IO() tak, aby se toto plýtvání pamětí odstranilo a aby bylo trochu konzistentnější s ostatními operacemi s adresovým prostorem. To dělá Jensův patch, s ním rozhraní vypadá takto:

struct dio_args {
    int rw;
    struct page **pages;
    unsigned int first_page_off;
    unsigned long nr_segs;
    unsigned long length;
    loff_t offset;

    /*
     * Original user pointer, we'll get rid of this
     */
    unsigned long user_addr;
};

ssize_t (*direct_IO)(struct kiocb *iocb, struct dio_args *args);

V novém API je mnoho relevantních parametrů shromážděno do struktury dio_args. Paměť, která se má přenést, lze nalézt podle pages_array. Kód přímého I/O na vyšší úrovni VFS nyní řeší mapování bufferů v uživatelském prostoru a vytvoření pole pages.

Dopad tohoto kódu je poměrně malý; je to z větší části záležitost přesunu místa, kde se provádí překlad z adres v uživatelském prostoru na struktry page. Současný kód má potenciální problém v tom, že dokáže naráz zpracovat pouze jeden I/O segment, což může pro některé druhy aplikací znamenat výkonnostní problémy. Tento režim práce není nicméně do systému skutečně zadrátován, takže ho v nějakém bodě bude pravděpodobně možné opravit.

Jediná námitka přišla od Andrewa Mortona, kterému se nelíbí způsob, jakým Jens implementoval proces průchodu polem struktur page. Index do tohoto pole (nazvaný head_page) je zabudován do struct dio a skryt před kódem, který prochází stránkami; to vede k potenciálnímu zmatení, obzvláště pokud se operace ukončí v polovině. Andrew to nazval katastrofou, která čeká na svou příležitost, a doporučil, aby bylo indexování explicitnější tam, kde se zpracovává pole pages.

To je ale detail, i když možná důležitý. Základní cíle a implementace byly, zdá se, přijaty poměrně dobře. Zdá se velmi nepravděpodobné, že tento kód stihne začleňovací okno 2.6.32, ale téměř určitě ho uvidíme mířit do hlavní řady v následujícím vývojovém cyklu.

Vývojové statistiky 2.6.31

Linux Foundation nedávno oznámila vydání aktualizované verze své zprávy o autorství jádra, na které spolupracoval redaktor LWN Jonathan Corbet. Informace v ní zmiňovaná je zajímavá, ale vzhledem k tomu, že končí jádrem 2.6.30, je to v tuto chvíli dávná historie. 2.6.30 již přece vyšlo před celými dvěma měsíci. Čtenáři Jaderných novin jsou rozhodně zvyklí na aktuálnější informace a vzhledem k tomu, že jádro 2.6.31 se blíží k dokončení, zdá se být ta správná chvíle podívat se na tento vývojový cyklus a zjistit, odkud kód přišel tentokrát.

V době psaní tohoto článku (těsně po vydání 2.6.31-rc7) bylo součástí vývojového cyklu 2.6.31 začlenění 10 633 neslučovacích sad změn od 1 146 vývojářů. Tyto patche přidaly téměř 903 000 řádků kódu a odebraly těsně nad 494 000 řádků, takže celkový přírůstek je něco přes 408 000 řádků. Podle hlášení Rafaela Wysocki tato práce do jádra zavlekla 108 regresí, z nichž 26 stále ještě není vyřešeno.

Nejvýznamnější jednotlivci, kteří přispěli do vývojového cyklu 2.6.31, byli:

Nejaktivnější vývojáři 2.6.31

Podle sad změn Ingo Molnár 276 2,6 % Peter Zijlstra 260 2,4 % Paul Mundt 204 1,9 % Takashi Iwai 150 1,4 % Bartlomiej Zolnierkiewicz 149 1,4 % Steven Rostedt 139 1,3 % Tejun Heo 134 1,3 % Johannes Berg 133 1,2 % Magnus Damm 119 1,1 % Mike Frysinger 115 1,1 % roel kluin 105 1,0 % Greg Kroah-Hartman 101 0,9 % Erik Andrén 100 0,9 % Paul Mackerras 85 0,8 % Mark Brown 85 0,8 % Bill Pemberton 82 0,8 % Jaswinder Singh Rajput 79 0,7 % Ben Dooks 72 0,7 % Joe Perches 72 0,7 % Alexander Beregalov 71 0,7 %

Podle změněných řádků Bartlomiej Zolnierkiewicz 220749 18,3 % Jerry Chuang 78441 6,5 % Forest Bond 50834 4,2 % David Daney 40052 3,3 % Jerome Glisse 38604 3,2 % Vlad Zolotarov 23260 1,9 % Ingo Molnár 22614 1,9 % James Smart 19209 1,6 % Bill Pemberton 17249 1,4 % dmitry pervushin 14532 1,2 % Greg Kroah-Hartman 13234 1,1 % Wai Yew CHAY 12741 1,1 % Michael Chan 11887 1,0 % Linus Walleij 11626 1,0 % Paul Mundt 10735 0,9 % Peter Zijlstra 10202 0,8 % Zhu Yi 10197 0,8 % Ben Dooks 10150 0,8 % Johannes Berg 9532 0,8 % Kalle Valo 9263 0,8 %

Ingo Molnár se vždy ukáže někde poblíž vrcholku statistik sad změn. Jako obvykle přispěl prací v celém jádře a v kódu architektury x86, ale jádrem jeho práce je tentokrát kód čítačů výkonnosti; většina příspěvků Petera Zijlstry byla také v této oblasti. Začlenění tohoto rychle se měnícího subsystému způsobilo, že jsou tito dva vývojáři zodpovědní za 5 % patchů, které se dostaly do jádra 2.6.31. Paul Mundt napsal ohromné množství patchů pro architekturu Super-H a Takashi Iwai přispěl velkým počtem patchů pro ALSA.

Páté místo v žebříčku sad změn obsadil Bartlomiej Zolnierkiewicz, který také obsadil první místo v počtu změněných řádků. Přispěl několika IDE patchi, přestože se vzdal odpovědnosti za tento subsystém, ale většina jeho práce spočívala v pročištění bezdrátových ovladačů Ralink ve stromě staging. Toto pročištění vedlo k odstranění úžasných 208 000 řádků kódu. Jerry Chuang přidal (do staging) bezdrátový ovladač RealTek RTL8192SU, Forest Bond přidal (do staging) ovladač VIA Technologies VT6655, David Daney odvedl práci na MIPS (včetně přidání ethernet ovladače Octeon do staging) a Jerome Glisse přidal podporu jaderného nastavování režimu [KMS] pro grafické čipové sady Radeon.

Jak jsme viděli v několika minulých vývojových cyklech, strom staging je zdrojem většiny změn v jaderném stromě. Podoba těchto změn se ale sama mění, příliv ovladačů do stromu staging se významně zpomalil; začínáme vidět víc práce věnované tomu, aby byl opraven kód, který tam již je.

Vývojáři přispívající do 2.6.31 byli podporováni minimálně 194 zaměstnavateli. Nejaktivnější z nich byli:

Nejaktivnější zaměstnavatelé 2.6.31

Podle sad změn (žádný) 1704 16,0 % Red Hat 1587 14,9 % Intel 878 8,2 % (neznámý) 846 7,9 % IBM 667 6,3 % Novell 614 5,8 % Renesas Technology 345 3,2 % Fujitsu 223 2,1 % (konzultant) 212 2,0 % Analog Devices 212 2,0 % Oracle 175 1,6 % Nokia 131 1,2 % AMD 129 1,2 % Atheros Communications 118 1,1 % MontaVista 104 1,0 % Xelerated AB 100 0,9 % (školství) 92 0,9 % NetApp 91 0,9 % HP 86 0,8 % Wolfson Microelectronics 85 0,8 %

Podle změněných řádek (žádný) 311803 25,8 % Red Hat 124831 10,3 % Realtek 78441 6,5 % Intel 62559 5,2 % Broadcom 51806 4,3 % Logic Supply 51401 4,3 % (neznámý) 47165 3,9 % Cavium Networks 40086 3,3 % IBM 39991 3,3 % Novell 31979 2,6 % Renesas Technology 31674 2,6 % (konzultant) 23659 2,0 % Emulex 19209 1,6 % University of Virginia 17607 1,5 % Nokia 16234 1,3 % Embedded Alley Solutions 15229 1,3 % Creative Technology 12741 1,1 % Oracle 11704 1,0 % Analog Devices 10760 0,9 % Texas Instruments 10639 0,9 %

Nejvyšší příčku v obou skupinách obsazují vývojáři, kteří pracují ve svém volném čase, následuje Red Hat, který tentokrát začlenil několik velkých kusů kódu.

Pohled na neautorské podpisy (náznak toho, který správce subsystému přijal patch do hlavní řady) ukazuje pokračování stávajícího trendu:

Nejvíce neautorských podpisů v 2.6.31
Jednotlivci David S. MIller 964 10,1 % Ingo Molnár 948 9,9 % Greg Kroah-Hartman 582 6,1 % John W. Linville 575 6,0 % Andrew Morton 569 6,0 % Mauro Carvalho Chehab 535 5,6 % Linus Torvalds 254 2,7 % James Bottomley 237 2,5 % Benny Halevy 191 2,0 % Paul Mundt 159 1,7 %	Zaměstnavatelé Red Hat 3686 38,7 % Novell 1061 11,1 % Intel 829 8,7 % Google 572 6,0 % (žádný) 422 4,4 % IBM 383 4,0 % Linux Foundation 254 2,7 % Oracle 228 2,4 % Panasas 193 2,0 % (konzultant) 168 1,8 %

49,8 % patchů se do hlavní řady dostalo přes vývojáře pracující pro pouhé dvě společnosti: Red Hat a Novell. Jaderní vývojáři pracují v mnoha firmách, ale správci subsystémů jsou čím dál tím více koncentrováni na velmi malém množství míst.

V souhrnu jde o poměrně typický vývojový cyklus, počet změn je vysoký (ale rekordní ne), stejně jako počet vývojářů. Dočasný vliv stromu staging začíná odeznívat, stává se z něj jenom další cesta, jakou se do hlavní řady mohou dostat ovladače. Jako celek se vývojový proces zdá být funkční; uhlazený a robustní.

(Jonathan Corbet, autor článku, jako vždy děkuje Gregu Kroah-Hartmanovi za pomoc při přípravě těchto statistik.)

HWPOISON

Originál tohoto článku pro LWN.net napsal Jon Ashburn

Jednou nevýhodou neustále se zvětšujících pamětí dostupných počítačům jsou častější selhání. Jak roste hustota paměti, rostou i počty chyb. Aby se tento nárůst vykompenzoval, obsahují současné procesory podporu pro „otrávenou“ paměť, adaptivní metodu pro označení chyb paměti a zotavení z nich. Patch HWPOISON, který nedávno vyvinuli Andi Kleen a Fengguang Wu, poskytuje na straně linuxového jádra podporu pro otrávení paměti. Takže, když je HWPOISON spárováno s odpovídajícím procesorem tolerujícím chyby, si uživatelé Linuxu mohou užívat systémy, které jsou méně citlivé na chyby i přes zvyšující se hustotu paměti.

Chyby paměti jsou klasifikovány jako měkké (přechodné) a tvrdé (trvalé). U měkkých chyb může kosmické záření nebo náhodná chyba změnit stav bitu v paměťové buňce SRAM nebo DRAM, u tvrdých chyb jde o fyzicky degradované paměťové buňky. Hardware může zjistit – a automaticky opravit – některé z těchto chyb pomocí kódů pro nápravu chyb [Error Correcting Codes, ECC]. Zatímco jednobitové chyby lze pomocí ECC opravit, vícebitové ne; pro takové neopravitelné chyby hardware typicky vygeneruje past, která následně vyvolá kernel panic.

Vyvolat pád stroje pro všechny neopravené měkké i tvrdé chyby paměti je občas přehnaná reakce. Pokud nalezená chyba paměti nepoškozuje běžící software, je nejlepší chybu ignorovat nebo izolovat. „Otrávení“ paměti se svým zpožděným řešením chyb umožňuje citlivější zotavení a izolaci neopravených paměťových chyb místo toho, aby vyvolalo pád systému. Potřebuje však podporu v hardwaru i v jádře.

Patch HWPOISON přichází opravdu načas: Nedávné poodhalení procesoru Xeon (s kódovým jménem Nehalem-EX) slibuje podporu pro otrávení paměti, Intel do Nehalem-EX zařadil architekturu Zotavení po Machine Check Abort (MCA). Tato architektura podporuje otrávení paměti a další mechanismy pro obnovu po selhání hardwaru. Je potřeba říci, že HWPOISON převzal používání termínu „otrava“ od Intelu, ale to by nemělo být zaměňováno s konceptem otrávení linuxovým jádrem, což je zapisování vzoru do paměti, aby se odchytila neinicializovaná paměť; tyto vlastnosti spolu nesouvisí.

I když se specifika toho, jak jádro a hardware mohou implementovat otrávení paměti, různí, základní koncept je následující: Hardware nejprve detekuje neopravitelnou chybu při přenosu z paměti do cache systému nebo systémové sběrnice. Alternativně může být paměť příležitostně „vydrhnuta“, tj. proces na pozadí může vyvolat ECC kontrolu jedné nebo více stránek v paměti. V obou případech hardware místo okamžitého vyvolání kontroly stroje [machine check] označí data jako otrávená, dokud nebudou přečtena (nebo převzata). Když jsou později data čtena vykonávaným softwarem, je spuštěna kontrola stroje; pokud chybná data nejsou čtena nikdy, kontrola stroje není zapotřebí. Například změněný řádek v cache, který je zapisován zpět do hlavní paměti, může obsahovat datové slovo, které je označené jako otrávené. Jakmile jsou tato otrávená data skutečně použita (nahrána do registru procesoru atd.), dojde ke kontrole stroje, dříve ne. Kontrola stroje po otravě tedy může nastat dlouho po s ní spojené chybě v datech.

HWPOISON je obsluha pro otrávená data spouštěná nízkoúrovňovým kódem pro kontrolu stroje. Když je to možné, pokouší se HWPOISON po chybě o zotavení a snaží se přitom izolovat chybující hardware, aby k dalším chybám nedocházelo. Na první pohled je pro obsluhu chyby zjevné řešení zaměřit se na specifický proces a paměťovou adresu (adresy) spojené s chybnými daty. To ale ze dvou důvodů nevyhovuje: Prvním je to, že kvůli zpoždění mezi použitím chybných dat a spuštění obsluhy chyby nelze zjistit chybně provedenou operaci a proces – když je obsluha HWPOISON připravena k práci, může již běžet jiný proces. Za druhé – izolaci špatné paměti je nutné provést na úrovni, na jaké jádro spravuje paměť. HWPOISON se tedy zaostřuje na izolaci paměti s granularitou na jednotlivé stránky místo s menší granularitou podporovanou hardwarem „Zotavení po MCA“ od Intelu.

HWPOISON najde stránku obsahující otrávená data a pokusí se ji izolovat od dalšího používání. Potenciálně poškozené procesy poté lze nalézt vyhledáním všech procesů, které mají poškozenou stránku namapovánu. HWPOISON provádí různé další akce, jeho přesné chování závisí na typu poškozené stránky a různých konfiguračních parametrech jádra.

Obsluha HWPOISON se povoluje nastavením jaderného konfiguračního parametru MEMORY_FAILURE – pokud není nastaven, otrava hardwarem vyvolá kernel panic. Kromě toho musí otrávení dat podporovat architektura; v době psaní tohoto článku je HWPOISON povolené pro všechny architektury, aby se umožnilo testování pomocí vkládání chyb v uživatelském režimu, což je rozebráno níže.

Obsluha musí umožnit to, že se během krátké doby objeví několik událostí otravy. HWPOISON používá bit v poli flags ve struktuře struct page, kterým označuje a zamyká stránku jako otrávenou. Vzhledem k tomu, že příznaků je v současnosti nedostatek, toto rozhodnutí konsternovalo jaderné vývojáře a vyvolalo debatu. Více detailů o tomto tématu vizte v článku Kolik příznaků stránek opravdu máme? V každém případě tento bit umožní obsluze ignorovat dříve otrávené stránky.

Kromě již dříve otrávených stránek obsluha ignoruje stránky, které jsou 1) mimo kontrolu jádra (mají neplatné číslo rámce stránky), 2) rezervované jaderné stránky a 3) stránky s počtem využití 0, což znamená volné stránky nebo jaderné stránky vyššího řádu. Bit indikující otravu slouží jako zámek, který umožní obsloužit rychle po sobě jdoucí kontroly stroje pouze jednou a následující volání obsluhy ignorovat, pokud se týkají stejné stránky. Rezervované jaderné stránky a stránky s nulovým počtem odkazů jsou ignorovány s rizikem kernel panic. Tyto stránky obsahující kritická jaderná data nicméně nelze izolovat, HWPOISON tedy nemá žádné užitečné možnosti obnovy.

Kromě ignorování stránek mezi možné akce HWPOISON patří obnova, zpoždění a selhání. Obnova znamená, že HWPOISON přijal opatření, kterými stránku izoloval. Ignorování, selhání a zpoždění jsou podobné v tom, že stránka nebyla zcela izolována, pouze označena jako otrávená. Se zpožděním lze obsluhu bezpečně odložit na později, až bude na stránku odkazováno. Zpožděním se některé přechodné chyby nemusí objevit znovu nebo mohou být irelevantní. Při selhání by se HWPOISON mohl, ale zatím to nepodporuje, o danou stránku postarat. HWPOISON volí selhání pro neznámé nebo obrovské stránky. Obrovské stránky selžou, protože není podporováno reverzní mapování, jež by identifikovalo proces, který stránku vlastní.

Čisté stránky ve swapu nebo v cache stránek lze snadno obnovit tím, že se pro tyto stránky zneplatní záznam v cache. Vzhledem k tomu, že tyto stránky mají kopii na disku, lze zneplatnit kopii v cache v paměti. Na rozdíl od toho špinavé stránky v těchto cachích mohou obsahovat rozdíly mezi kopiemi v paměti a na disku; otrávené špinavé stránky tedy mohou obsahovat poškozená důležitá data. I tak jsou však špinavé stránky v cache stránek obnoveny zneplatněním cache. K tomu je navíc pro špinavou stránku nastavena chyba stránky, takže následující systémová volání pro soubor spojený s danou stránkou vrátí I/O chybu. Špinavé stránky v cache swapu jsou řešeny se zpožděním. Příznak špinavosti je pro stránku vynulován a ponechá se záznam v cache stránek swapu. Při pozdějším výpadku stránky je zabita související aplikace.

Aby se vzpamatoval z otrávených stránek mapovaných uživatelským prostorem, HWPOISON nejprve hledá všechny uživatelské procesy, které poškozenou stránku mapovaly. Pro stránky, které jsou na úložišti čisté, nemusí HWPOISON dělat nic, protože proces není potřeba zabít. Špinavé stránky jsou odmapovány od procesů s nimi spojených a tyto procesy jsou následně zabity. Co se týče zabíjení uživatelských procesů, podporuje HWPOISON dva sysctl parametry VM: vm.memory_failure_early_kill a vm.memory_failure_recovery. Nastavení parametru vm.memory_failure_early_kill způsobí, že je uživatelskému procesu (procesům) okamžitě zaslán SIGBUS. Zabití je provedeno zachytitelným SIGBUS s BUS_MCEERR_AO. Procesy se tedy mohou rozhodnout, jak budou otravu dat řešit. vm.memory_failure_recovery zabití opozdí: Stránka je HWPOISON pouze odmapována. Teprve když je na odmapovanou stránku později skutečně odkázáno, vyšle se SIGBUS.

Gitový repozitář HWPOISON je k dispozici na:

git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-mce-2.6.git hwpoison

Vzhledem k tomu, že je těžko k sehnání vadný hardware, který podporuje otravu dat, bylo také vyvinuto vkládání chyb mm/hwpoison-inject.c. Tento jednoduchý nástroj používá debugfs a umožňuje s jeho pomocí vložit chyby do libovolné stránky.

I když bylo HWPOISON vyvinuto pro stroje založené na x86, příznivci jiných serverových architektur, na kterých běží Linux, jako je sparc a ia64, již vyjádřili zájem (diskuse). Patch se tedy může dostat do budoucích serverových distribucí Linuxu, což budoucím uživatelům linuxových serverů umožní užít si zvýšené odolnosti vůči chybám. Nyní, když Intel podporuje obnovu MCA na strojích x86, si její výhody mohou v budoucnu užít i někteří uživatelé desktopů.

       

Komentáře

[martin()]

sledgehammer == palica ? :-/

[Andrej Herceg]

Nie, ale sledgehammer == palice ;)

[martin()]

Tak toto by ma ani vo sne nenapadlo

[Semo]

Cesky je palica bud palica, alebo hlava, alebo velke kladivo. Takze je to spravne.

[Semo]

Alebo este hul.

[Tyfus]

Vy jste mi češtináři.

Kovářské kladivo se odjakživa jmenuje „perlík“.

[Marián André]

Hm, tuším kladivko na rozklepávanie mäsa je v češtine palička... (?)

[trekker.dk]

Co se začlenění TuxOnIce týče, tak je škoda, že to neklaplo - mezi ty jeho "hezké" vlastnosti třeba patří to, že umí uspat a probudit X.org s binárními ovladači nvidia, což suspend v hlavní řadě jaksi moc ne-e.

[Robert Krátký]

Moje distribuční jádro (Debian, 2.6.30) to umí - jen pak nefunguje nastavení pomocí nvidia-settings. Ale pokud to člověk nepotřebuje, tak je vše v pohodě.

[trekker.dk]

Já jsem to zkoušel tuším s 2.6.29 (možná .28) made in udělej si sám, když se na tuxonice-dev diskutovalo o začlenění do jádra. Aby se stroj probudil, musel jsem ten modul úplně vyndat. (Ale možná něco vylepšili, časem to zkusím)

[Jiri Slaby]

K tomu zacleneni: neni se cemu divit, ten kod neni uplne koser. Nicmene zaclenovat se bude. Ale ne jako samostatny "swsusp". Misto toho bude soucasny swsusp vylepsen.

 

Ano, nvidia muze byt problem pro upstream swsusp. Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek? nvidia dela velke alokace behem suspendu a ten soucasny objem ji nemusi stacit. Pricemz si dokazu predstavit, ze ikdyz alokace selze, tak oni vrati nechybovy stav. TOI pouziva std. 2M.

[trekker.dk]

K tomu zacleneni: neni se cemu divit, ten kod neni uplne koser.

Což to je mi jasný.

Ale ne jako samostatny "swsusp". Misto toho bude soucasny swsusp vylepsen.

Nic proti - pokud se tam teda dostanou všechna vylepšení, která potřebuju, aby mi swsusp fungoval.

Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek?

Zkusim, až se v tom zase budu někdy rejpat.

[trekker.dk]

Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek?

Zvýšil jsem, pomohlo*. Dám tomu pár dní testování a uvidíme, jestli se něco nepokazí. (sync před uspáním jsem dělal už doteď a budu v tom pokračovat )

[Andrej]

Situace kolem uspání a hibernace je momentálně v Linuxu tragická. Dalo by se to shrnout asi takto:

• Hibernace, která je přímo v mainline kernelu, se nikdy neprobudí. Nemá smysl to vůbec zkoušet. Nechápu, proč tam vůbc je. Mělo by tam být upozornění, označení EXPERIMENTAL a podobně. Jen ohrožuje data důvěřivých uživatelů a nepřináší žádný užitek.
• Do verze 2.6.28.x fungoval znamenitě TuxOnIce. Od té doby (a od zavedení věcí kolem KMS) buď nefunguje vůbec, nebo zrovna pro daný kernel nejsou patche. Celkově se tedy dá říct, že momentálně funkční hibernace pro Linux neexistuje.
• Uspání do RAM fungovalo bezproblémově, ba znamenitě až do verze 2.6.28.x. Od této verze už uspání do RAM nefunguje. Problém už není v tom, že by se systém neprobudil. On se ani neuspí, jen se zasekne.

Fakt nechápu, jaká převratná změna musela ve verzi 2.6.29 přijít, že to všechny věci kolem uspání do RAM a hibernace poslalo do kytek. Nehledě na fakt, že nové ovladače grafiky Intel jsou už několik měsíců rozbité a nedá se s nimi pracovat. Takže ani toho slavného KMS si člověk neužije.

 

[Filip Jirsák]

Píšete o Linuxu obecně, nebo o jedné nebo několika málo instancích na vašem počítači, případně pár počítačích okolo?

[Andrej]

O Linuxu obecně. Do verze 2.6.28 mně na mých počítačích i všem známým, kteří používají Linux, funovala hibernace bez potíží a totéž platilo o uspání do RAM. Od verze 2.6.29 nevím o nikom, komu by tohle fungovalo.

Pokud je tu někdo s vanilla kernelem verze 2.6.29 a vyšší, komu funguje buď uspání nebo hibernace, ať už s TuxOnIce nebo s původní (podle mě nebezpečnou a nefunkční) implementací, moc rád se od něj něčemu přiučím.

Kdysi jsem řešil problém, že po probuzení počítače z hibernace mi nefungoval IRDA port a musel jsem ho ručně zapnout. Dokonce jsem to hlásil jako bug a vývojáři TuxOnIce to dali do pořádku prakticky okamžitě. Nicméně ve srovnání s dnešní situací se mi nefunkční IRDA zdá jako titěrný a nesmyslný problém.

[CIJOML]

2.6.31 vanilla original EEE901 funguje do RAM i na disk - na Prestigio 159W to same - vzdy posledni vydany bios

 

[Filip Jirsák]

A přibližně se to týká třech lidí nebo tří set? A ti vaši známí mají různý hardware, různé konfigurace softwaru atd., nebo všem svým známým doporučujete osvědčenou značku základních desek a čipsetů, a teď je s tou jednou řadou problém, a vy to zobecňujete na vše? Z toho původního komentáře to není poznat, a vzhledem k tomu, že se tady v diskusi objevují i komentáře od lidí, kterým to funguje, ta vaše generalizace se mi zdá přehnaná. Ne že by zrovna mně fungovalo uspávání počítačů pod Linuxem bez problémů, ale v mém případě je to spíš rukama a neochotou to řešit, protože u desktopu mi delší boot ráno nevadí, a u notebooku nefunkční touchpad po probuzení nějak přežiju, stejně ho používám nerad.

[Andrej]

Týká se to (odhadem) deseti lidí. Hardware mají v podstatě různorodý, někdo starší 32-bit, někdo 64-bit, různé značky. Já nikomu nic nedoporučuju, hardwarem se nezabývám a neradím lidem, co si koupit.

Přiznám se, že kdybych pečlivě hlásil každý bug a snažil se zachytit aspoň jednu rozumnou logovou hlášku přes netconsole, možná by se to dalo vyřešit. Už takové věci nedělám, přece jen toho elánu nemám tolik jako dřív. Ono se to těžko řeší, když ten stroj odporně zatuhne. Pak nezbývá než přebootovat, zkusit vyhodit nějaký modul, znova zkusit uspat... Na to už prostě nemám nervy. A mám dojem, že před cca třemi lety tam byly mnohem menší problémy (například IRDA), které navíc bylo možné nějak vyřešit. Dnes vidím jenom sekanec a nemám tušení, co se tam děje.

[Jendа]

Hibernace, která je přímo v mainline kernelu, se nikdy neprobudí.

Nemáte pravdu, mně se probouzí úplně bez problémů. Takže určitě neplatí nikdy. Jádra 2.6.24 - 2.6.30, předtím jsem hibernaci nezkoušel.

Nemá smysl to vůbec zkoušet.

Vyzkoušel jsem, fungovala mi na první pokus (distribuční jádra Archu a Debianu). Pravda, pak jsem chtěl obraz paměti šifrovat a na to bylo potřeba upravit skripty v initramdisku, ale bez šifrování mi to šlo v pohodě.

Nechápu, proč tam vůbc je.

Nevím, ale řekl bych, že proto, aby fungovala hibernace.

Jen ohrožuje data důvěřivých uživatelů

To tedy nevím, jak může neprobuzení se ohrozit data. Filesystém na tom bude stejně, jako kdyby vypadla elektřina.

a nepřináší žádný užitek.

Mně se hibernace docela hodí - spouštění všech služeb trvá strašně dlouho, takhle mám za chvilku počítač přesně v tom stavu, v jakém jsem ho uspal.

Fakt nechápu, jaká převratná změna musela ve verzi 2.6.29 přijít, že to všechny věci kolem uspání do RAM a hibernace poslalo do kytek.

Žádných problémů jsem si nevšiml. Akorát jsem trochu zápasil v VirtualBoxím modulem.

[Andrej]

Já mám vanilla kernel, takže to nemá smysl takhle srovnávat. Distribuční kernel jsem nikdy nezkoušel a ani to nemám v plánu.

Mně původní hibernace ještě nikdy nefungovala. Pravda je, že jsem to zkoušel jen cca desetkrát, ale pokaždé to naprosto spolehlivě selhalo. Počítač se buď neprobudil, nebo se vůbec neuspal a zatuhl. TuxOnIce donedávna fungoval spolehlivě.

Mně už původní hibernace při jednom z pokusů o uspání poškodila filesystém. Konkrétně to byl Reiser4 a byl to jeden z mála případů, kdy jsem ho musel opravovat pomocí fsck. Mám za to, že se jednalo o něco vážnějšího než ekvivalent výpadku napájení.

Užitek přináší pouze spolehlivá a funkční hibernace. TuxOnIce byl až donedávna ideálním řešením. To, co je dnes v kernelu, mi spolehlivé nepřipadá. I s uspáním do RAM byl problém, protože počítač se cca při každém desátém uspání neprobudil. Jakmile to nemá rozumnou spolehlivost, nemá to smysl. Dnes už mi uspání do RAM nefunguje vůbec, takže je to fuk.

Asi nemá smysl to nějak řešit. Třeba mám špatný BIOS. Taky už jsem líný při každém selhání shromažďovat logy a hlásit bug, což jsem dřív dělával.

[stativ]

Co se týče Reiser 4 tak bych to zas tak neházel na hibernaci. Ačkoliv FS je (byl?) to určitě pěkný, slyšel jsem na něj docela dost nadávek co se týče poškození FS.

A jen tak mimochodem Arch používá vanilku.

[M. Lox]

Ačkoliv FS je (byl?) to určitě pěkný

Je.

slyšel jsem na něj docela dost nadávek co se týče poškození FS.

Taky už se mi párkrát rozsypal, ale vždycky to bylo hardwarem. (Vadný disk || vadná RAM || vadný kabel) == (fsck.reiser4: Read nodes: 12345678, Nodes left in tree: 1234567) .

[Patrik Uhrak]

Ja som sa ale napr. od kernelu 2.6.28 az po 2.6.31 s problemom uspania do ram a nasledneho prebudenia nestretol a pouzivam to kazdy bozi den. Mam ale nvidia kartu a driver z oficialnych stranok. Mozno je to tou intel grafikou, mozno niecim inym na tvojom stroji, no u mna to ide. Co sa tyka hibernacie, to nepouzivam, neviem potvrdit.

[trekker.dk]

Aby těch věcí, kdy prohlašuje něco, co platí pro tebe, za všeobecně platné, nebylo málo, tak

Do verze 2.6.28.x fungoval znamenitě TuxOnIce. Od té doby (a od zavedení věcí kolem KMS) buď nefunguje vůbec

Pro 2.6.29 byl patch a TOI fungoval naprosto bez problémů, nedávno jsem rebootoval s 33 dní uptime.

nebo zrovna pro daný kernel nejsou patche.

Pro 2.6.30 patch nebyl, ale zato se v mailing listu objevila adresa na gitový strom, ze kterého se nechalo 2.6.30 udělat a TOI fungoval. Pro 2.6.31 patch je, používám na dvou strojích a na obou funguje.

[Andrej]

Možná mám špatný BIOS.

[Josef Kufner]

Jak hibernace co je v kernelu, tak uspávání do RAM mi funguje s téměř 100% úspěšností. Nebude to klasický PEBKAC ?

[Mandarinka]

Spíš to (ne)funguje na konkrétním hardware... HIbernace (na linuxu) nikdy nebyla spolehlivá v tom, že by běžela všude.

[xm]

Já s vámi nemohu souhlasit. Mám přesně opačnou zkušenost - s jádry do 2.6.28 (včetně) mi suspend to RAM nefungoval (fungoval v nějakých hodně starších, ale pak přestal jít, jestli si správně pamatuju někdy okolo 2.6.26). Jádro 2.6.29 to zpravilo a v 2.6.30 taktéž funguje perfektně. Suspend to disk (hibernace) mi fungoval snad vždy. Testováno na 2 strojích s čipovou sadou a grafikou AMD/ATI.

[xm]

Jen doplním, že používám oficiální suspend z vanilla kernelu. Žádné sr**ky jako TuxOnIce mi do systému nesmí

[trekker.dk]

Žádné sr**ky jako TuxOnIce mi do systému nesmí

Vy jste, pane, vůl.

[xm]

Nápodobně, pane Vy mi také lezete už delší dobu krkem, obzvláště v diskuzích o KDE a politice, arogance z vás z nich přímo čiší.

[Jiri Slaby]

Ne, neni vul. Jen spravne tusi/vi, ze TOI pouziva strasne moc hacku.

[Blaazen]

Dobrý den, moje zkušenost je taková, že na nový notebook (čipset a CPU Intel) jsem zkoušel dát v červenci Debian s jádrem 2.6.26 a z hibernace i ze Suspend To RAM se to probudilo rovnou do kernel panic. Zkoušel jsem všemožná nastavení, upgrade jádra na 2.6.30 a nic nepomohlo (čímž nevylučuju problém ve mně, tehdy jsem s Linuxem spíš začínal). Pak jsem zkusil Kubuntu 9.04 s jádrem 2.6.28 a šlo to hned, bez nastavování. Od té doby 100% funkčnost. B.

[Nicky726]

Nehledě na fakt, že nové ovladače grafiky Intel jsou už několik měsíců rozbité a nedá se s nimi pracovat. Takže ani toho slavného KMS si člověk neužije.

Včera jsem nahodil aktuální Arší intel ovladače, podle wiki zapnul KMS, rebootoval a měl funkční grafiku včetně KMS. Žádné problémy s grafikou jsem zatím nezaregistroval.

[Andrej]

Právě dnes ten bug uzavřeli, prý už to funguje a nedochází k zamrznutí.

Nicméně otázka je, za jakých podmínek. Například já mám dual head konfiguraci 1050x1680 svisle a 1024x768 vodorovně s překrytím 90 pixelů (aby virtuální screen nepřesáhl limit pro 3D akceleraci). S něčím takovým má KMS pořád těžký problém.

[Jiri Slaby]

Apeluji na vas, abyste to reportovali. Ikdyz se vam nechce. Takhle to nebudete mit funkcni nikdy. (Ano, na muj vkus linux az moc testovani prenasi na lidi. Ale zaroven nevim, jak to zlepsit.)

[ticcky]

 Nechci rypat, ale nerozumnel jsem vtipu v komentari ve zdrojaku v citacich, tak jsem se koukl na original... =)

v orig. zni takto:

/* Promote an attitude of violence to a BIOS engineer today */

 

a v cestine je to podle me:

/* Dnes podpor nasilny postoj k vyvojarum biosu */

 

[kralyk z abclinuxu]

Překlad v článku je určitě přesnější než cos napsal.

[stativ]

Přesnější není, ale nezní tak kostrbatě. U překladu jde o to najít překlad, který zní přirozeně ale zároveň je co nejpřesnější. Osobně spíš kladu důraz na přirozenost. Pokud chci doslovný překlad, který se nedá pořádně číst můžu použít překladač.

[snehuliak]

Suhlasim s ticcky s tym prekladom. Dufam ze takto zle sa neprekladaju cele jaderne noviny. Asi by som sa mal raz konecne pozriet na original....

[Patrik Uhrak]

Chyby su vsade, ja som ale velmi vdacny za preklady, aj ked mozno len 99,9% spravne. Je to to vyborne citanicko, aj ked zvacsa tomu velmi nerozumiem :D ale to je druha strana mince. Takze dakujem autorovi prekladu.

[Andy]

+1

[kralyk z abclinuxu]

Já zas doufám, že nikdo nebude překládat JN tak špatně jako ticcky

[Jirka]

Jak na zkousku uzavrit popisovac 2, abych si mohl vyzkouset to chovani pri uzavrenem popisovaci?

[Michal Vyskočil]

#include <unistd.h>
close(STDERR_FILENO);

[petr_p]

V bashi stačí za příkaz přidat 2>&-.

[geebranz]

Good innovator

polebarnssalemor.com