Jaderné noviny – 19. 5. 2010

14. 6. 2010 | Jirka Bourek | Jaderné noviny | 3906×

Aktuální verze jádra: 2.6.34. Citáty týdne: Linus Torvalds, Daniela Torvaldsová, James Bottomley, Matthew Garrett. Zápisky z jaderného minisummitu o chybách hardwaru. Rozšířené červeno-černé stromy. SLEB alokátor. Začleňovací okno 2.6.35, část první. Problémy s čítačem časových značek (TSC). Zablokované blokování uspání.

Obsah

• Aktuální verze jádra: 2.6.34
• Citáty týdne: Linus Torvalds, Daniela Torvaldsová, James Bottomley, Matthew Garrett
• Zápisky z jaderného minisummitu o chybách hardwaru
• Rozšířené červeno-černé stromy
• SLEB alokátor
• Začleňovací okno 2.6.35, část první
• Problémy s čítačem časových značek (TSC)
• Zablokované blokování uspání

Aktuální verze jádra: 2.6.34

Není žádné vývojové jádro, protože začleňovací okno 2.6.35 je otevřené. V době psaní tohoto článku do hlavní řady proudí patche relativně pomalu; detaily vizte níže.

2.6.34 bylo vydáno 16. května. Jako obvykle je v tomto vydání spousta nových věcí, i když je o něco méně nabité novými vlastnostmi než jiná. Mezi nejvýznamnější patří asynchronní správa napájení, spousta vylepšení sledování, LogFS a distribuovaný souborový systém Ceph. Jako vždy lze spoustu detailů nalézt ve skvělém shrnutí na KernelNewbies.

V uplynulém týdnu nevyšly žádné stabilní aktualizace.

Citáty týdne: Linus Torvalds, Daniela Torvaldsová, James Bottomley, Matthew Garrett

Tabulkám BIOSu nevěříme, protože autoři BIOSů jsou vždy naprosto nekompetentní na cracku závislé opice. Kdyby nebyli, neprogramovali by BIOSy. Q.E.D.

-- Linus Torvalds

Když obejmeme každé
prase kolem sebe,
láska bude velká,
jako tahle země.

Tak slibuji, že pomohu
všem prasatům v bídě,
neb nebýt tady prasat,
nebude špek v jídle.

-- Daniela Torvaldsová

Správně, protože autoři Firmwaru jsou ze spálené nezodpovědné země z planety ignorujeme-stížnosti-uživatelů-a-žereme-je-k-snídani-když-nahlásí-chybu, kdežto autoři Softwaru jsou z jemných zodpovědných krajin planety harmonie. Je samozřejmé, že co funguje pro jedny, nefunguje pro druhé.

Jako autor softwaru s tímto pohledem na svět plně souhlasím. Problém je v tom, že když pak jdu na večeři s lidmi od hardwaru, zdají se to být strašlivě milí lidé… dokonce skoro úplně jako já…

-- James Bottomley

Jestliže se můj telefon dokáže vyhnout tomu, aby přišel o téměř celou pohotovostní dobu, aniž bych se musel starat o to, jestli hru s poskakující krávou napsal kompletní hlupák, znamená to, že můj telefon je lepší než ten, kde bych se o to starat musel. Byl by svět lepší, kdyby toho hlupáka někdo poslal do převýchovného tábora předtím, než by směl psát víc softwaru? Pravděpodobně jo, ale to bohužel není něco, co bychom dokázali implementovat kódem.

-- Matthew Garrett

Zápisky z jaderného minisummitu o chybách hardwaru

Několik vývojářů jádra se na Linux Foundation's Collaboration Summit zúčastnilo minisummitu věnovanému sběru a hlášení hardwarových chyb. Mauro Carvalho Chehab dal dohromady a zaslal nějaké poznámky z tohoto setkání; najdete je pod odkazem níže. Stojí za to poznamenat, že někteří vývojáři, kteří se nezúčastnili, zcela nesouhlasí se vším, co tam najdete; více informací naleznete v tomto diskuzním vlákně.

Celý článek na LWN.net.

Rozšířené červeno-černé stromy

napsal Jonathan Corbet, 18. května 2010

Červeno-černé stromy (rbstromy) [red-black trees, rbtrees] jsou vysoce optimalizované datové struktury používané v jádře na mnoha místech. S rbstromem může programátor jádra rychle nalézt datové struktury odpovídající specifické hodnotě; stačí uložit tyto datové struktury s touto hodnotou jako klíčem. Složitější vyhledávání však může být s rbstromy složitější; jako příklad uvažme případ, kdy potřebujeme najít uzel s nejnižší hodnotou, která spadá do daného rozsahu hodnot. Venkatesh Pallipadi nedávno narazil na tento problém, když se pokoušel vylepšit podporu tabulek atributů stránek [page attribute table, PAT] u architektury x86. Místo toho, aby se na rbstromy vykašlal, se rozhodl tuto datovou strukturu vylepšit tak, aby vyhovovala širším potřebám.

Venkateshův patch (který byl jednou z prvních věcí začleněných do 2.6.35) implementuje koncept „rozšířených rbstromů“ [augmented rbtree]. Takový rbstrom funguje v podstatě jako běžný rbstrom s tou výjimkou, že v každém uzlu uchovává informace navíc. Tato informace je téměř s jistotou funkcí kteréhokoliv uzlu potomka [child node] ve stromě – například maximální hodnota klíče mezi všemi potomky. Vzhledem k tomu, že uživatelé rbstromů si musí vyhledávací funkci napsat sami, mohou tuto informaci navíc snadno využít a optimalizovat s její pomocí vyhledávání.

Uživatelé vylepšených rbstromů musí definovat zpětné volání [callback] augment_cb() s prototypem:

void (*augment_cb)(struct rb_node *node);

Když je strom inicializován, zpětné volání by mělo být uloženo v jeho kořenovém uzlu:

struct rb_root my_root = RB_AUGMENT_ROOT(my_augment_cb);

Poté bude zpětné volání augment_cb() spuštěno pokaždé, když se hodnota jednoho (nebo obou) uzlů potomka mohla změnit. Zpětné volání pak může aktualizovat doplňující informace uzlu, aby platily pro aktualizovanou topologii stromu. Bude voláno z operací vkládání a mazání – mohou strom měnit – takže uživatelé rbstromů by měli zajistit, aby před vložením uzlů byly tyto uzly v konzistentním stavu.

Zpětná volání se nevolají rekurzivně směrem ke kořenu stromu. Jestliže se tedy změna rozšířené hodnoty uzlu může projevit výše ve stromě, volání augment_cb() se musí ke kořenu propracovat a provést potřebné aktualizace. Rekurzivní volání u rodičovského uzlu není dobrý nápad, kromě případů, kdy víme, že je strom extrémně mělký.

V době psaní tohoto článku je kód PAT jediným uživatelem této funkce ve stromě, ale pravděpodobně se objeví další, když je teď tato vlastnost globálně k dispozici.

SLEB alokátor

napsal Jonathan Corbet, 19. května 2010

Stálí čtenáři Jaderných novin ví, že jádro nemá jenom jeden vnitřní alokátor paměti. Máme zde starý „slab“ alokátor (který bude jednoho dne odstraněn), SLUB alokátor (měl mít lepší škálovatelnost, ale nepodařilo se mu porazit slab ve všech testech) a SLOB (efektivně pracující s místem, pro použití v embedded zařízeních). Také je zde alokátor SLQB, který čeká v povzdálí, ale čeká již tak dlouho, že je otázka, jestli se ještě někdy pohne.

Suma sumárum by se dalo říct, že alokátorů máme dost. Ale na druhou stranu v jmenném prostoru SL*B je ještě dost písmen, takže proč nevytvořit další?

Proto Christoph Lameter, autor alokátoru SLUB, přišel s alokátorem SLEB, jehož cílem je vzít to nejlepší ze slab a SLUB. Na rozdíl od SLUBu SLEB udržuje fronty objektů, které používá slab, ale také pro správu objektů přidává bitovou mapu. Další rozdíl oproti SLUBu je, že se v objektech samotných neukládají žádná metadata. To je výkonnostní zlepšení: Jestliže je alokován nebo uvolněn objekt se studenou cachí, SLEB ho do cache nenahraje.

Kód je velmi nový; pravděpodobně mu ještě nebylo svěřeno nic mimo virtuální stroj KVM. Dlouhý proces benchmarkování, který by mohl vést k začlenění a možná i k odstranění jednoho z ostatních alokátorů, ještě nezačal. Kód tu ale je a to je začátek.

Začleňovací okno 2.6.35, část první

napsal Jonathan Corbet, 19. května 2010

Je to tu zas: Začal nový vývojový cyklus jádra a v současnosti je otevřené začleňovací okno pro nový kód. V době psaní tohoto článku bylo do hlavní řady zařazeno nějakých 1100 neslučovacích sad změn. Nejvýznamnější změny viditelné pro uživatele jsou:

• Subsystém sledování výkonnosti nyní podporuje režim „precizní na událostech založené vzorkování“ [precise event based sampling, PEBS] od Intelu, ve kterém hardware přímo nahrává informace o událostech do vyhrazené oblasti v paměti. Subsystém perf také nyní dokáže získat informace o výkonnosti ze starých procesorů Pentium 4.

• Nástroj „perf kvm“, který umožňuje monitorování virtualizovaných hostů z hostitele, byl začleněn.

• Kód dynamických sond má nyní lepší podporu pro mnoho základních celočíslených typů

• Byly odstraněny konfigurační volby plánovače „fair sleepers“, „sync wakeups“ a „affine wakeup“. Zdá se, že vývojáři plánovače aktuálně mají za to, že bez těchto funkcí nebudou věci fungovat správně, takže jsou povoleny vždy.

• Architektura SuperH má nyní podporu pro přidávání/odebírání CPU za chodu.

• Nové ovladače:

  • Procesory a desky:

    • zařízení HP iPAQ rx1950,
    • systémy Acer N25,
    • systémy založené na Samsung S3C2416,
    • refereční desky Marvell GuruPlug,
    • jednodeskové počítače Voipac PXA270,
    • systémy Aeronix Zipit Z2,
    • procesory Cavium Networks CNS3xxx,
    • desky Cavium Networks CNS3420 MPCore,
    • desky taskit PortuxG20 and Stamp9G20,
    • systémy založené na ARM SPEAr3XX- a SPEAr6XX,
    • procesory Versatile Express CA9x4 a
    • desky ARM Ltd Versatile Express.

  • Různé: zařízení pro hodiny reálného času založené na DaVinci DM365

Mezi změny viditelné pro jaderné vývojáře patří:

• Mechanismus „cpu_stop“ (dříve cpuhog) byl začleněn. cpu_stop umožňuje jádru nakrátko zabrat jeden nebo více procesorů.

• Rozšířené rbstromy jsou nyní v hlavní řadě jádra.

• Makro INIT_RCU_HEAD() odchází; pro fungování RCU nikdy nebylo zapotřebí a ladění RCU se přesouvá do infrastruktury pro ladění objektů.

Jak je vidět, začleňovací okno 2.6.35 začalo poměrně pomalu. Podle starého rozvrhu by mělo zůstat otevřené do konce měsíce; spekuluje se o tom, že ho Linus tentokrát uzavře o něco dříve, aby ztížil život správcům, kteří budou s požadavkem na přetažení čekat příliš dlouho. Tak jako tak zde příští týden najdete další seznam změn.

Problémy s čítačem časových značek (TSC)

napsal Jake Edge, 19. května 2010

Čítač časových značek [time stamp counter, TSC] poskytovaný procesory x86 je čítač s vysokým rozlišením, který lze číst jedinou instrukcí (RDTSC), takže je lákavým cílem pro aplikace, které potřebují časové značky s jemným krokem. Bohužel je také poněkud nespolehlivý, takže jádro musí skákat skrz obruče, aby mohlo zjistit, jestli ho může použít, a zkusit detekovat, když je mimo. Snaha exportovat znalosti jádra o spolehlivosti TSC z mnoha důvodů narazila na silný odpor, přičemž největším z těchto důvodů je, že vývojáři jádra si nemyslí, že by vývojáři aplikací měli tento čítač používat přímo.

Dan Magenheimer a Venkatesh Pallipadi navrhli přidat adresář /sys/devices/tsc se záznamy odpovídajícími interním informacím jádra o TSC včetně příznaku tsc_unstable, který určuje, jestli jádro používá tento čítač jako stabilní zdroj hodin. Andi Kleen tento návrh zpochybnil:

Je to opravdu dobrý nápad? Podpoří to aplikace v používání RDTSC přímo, ale to má spoustu různých omezení. I pro jádro je těžké se s nimi vyrovnat – jak pravděpodobné je, že to aplikace udělá dobře?

K tomu přesně patch slouží, řekl Dan, protože aplikace nemají žádnou možnost, jak zjistit, jestli standardní systémové volání bude „rychlé“, nebo „pomalé“:

Z pohledu aplikace je problém v tom, že neexistuje žádné virtuální systémové volání [vsyscall]. Systémová volání jsou dvě: gettimeofday a clock_gettime. Občas máme štěstí a jsou velmi rychlá a občas nemáme štěstí a jsou VELMI pomalá (což způsobuje na výkonnostní postih 10 % či více), v závislosti na mnoha faktorech, které jsou mimo kontrolu aplikace a nelze je aplikací ani detekovat.

A je potřeba říci, že i vsyscall, který bude mít jako zdroj hodin TSC, bude významně pomalejší než rdtsc, obzvláště v obvyklém případě, kdy je značka rovnou uložena a později se dopočítává rozdíl mezi značkami; v případě vsyscall je každá časová značka volání funkce a konverze do nanosekund, kdežto u TSC je získání každé značky otázkou jediné instrukce.

V závislosti na hardwaru mohou být gettimeofday() a clock_gettime() implementovány jako virtuální systémová volání a ne jako standardní systémová volání, což odbourává přechod z uživatelského prostoru do jádra. Tato volání jsou uložena ve zvláštní oblasti paměti v uživatelském prostoru (oblast vdso), ze které lze přistupovat k datům spravovaným jádrem, jako jsou tiky hodiny. Virtuální systémová volání jsou (relativně) rychlá, ale na některém hardwaru (nebo ve virtuálním stroji) jsou potřeba operace v jaderném prostoru, které přistupují ke spolehlivému čítači, takže tato volání nelze použít a volání těchto funkcí je pomalejší. Pro aplikace, které potřebují získávat desítky nebo stovky tisíc časových značek za sekundu, je rozdíl výrazný.

Dan ale věří, že pokud jádro zjistí, že TSC je pro jeho účely dostatečně stabilní, je tím garantováno, že je použitelný i pro aplikace. Arjan van de Ven a Thomas Gleixner ale rychle přišli s upozorněním: Arjan poznamenal, že stabilita TSC se může za určitých podmínek změnit, a pak by chyběl způsob, jak na to aplikace upozornit. Jeho rada: Přátelé nenechají své přátele použít v kódu aplikace rdtsc.

Thomas to, jak se může TSC rozjet, rozebral detailněji, zmínil přerušení správou systému [system management interrupt, SMI], která si s TSC hrají, aby se skryla, různá jádra mohou obsahovat různé hodnoty kvůli rozdílům při bootu a/nebo připojování za chodu, u více pouzder zase hrozí rozdíly kvůli samostatným hodinám nebo kvůli rozdílům ve frekvenci závislých na teplotě. U TSC zkrátka není spolehlivé nic: Tenhle pitomý hardware není spolehlivý, ať už má na sobě nálepku ,Tvrdím, že jsem spolehlivý‘, nebo ne.. Thomas nicméně navrhl možnou alternativu:

[…] ale dokud nebudeme mít nějaký opravdu spolehlivý hardware, budu jakémukoliv vystavování ošklivých detailů do uživatelského prostoru dávat NACK jednoduše proto, že se pak musím potýkat se spadem, který z toho vznikne.

O čem se můžeme bavit, je rozhraní vget_tsc_raw() společně s vconvert_tsc_delta(), kde bude vget_tsc_raw() vracet ošklivý chybový kód u všeho, co nelze použít.

V současnosti existují nepojmenované „podnikové aplikace“, které se pokouší zjistit, jestli mohou TSC používat, a také to dělají, když si myslí, že ano – důvodem je nejistota panující ohledně výkonnosti gettimeofday() a spol. Dan navrhuje, že tuto informaci by bylo možné zpřístupnit:

Jádro ale nemá ani příznak „výkonnost gettimeofday stojí za prd“. Kdyby ano (nebo v případě patche, když by tsc_reliable bylo nulové), by se aplikace mohla alespoň rozhodnout, že vypne 10000-100000 značek za sekundu a zaloguje zprávu „používáš starý hardware a tak máš méně funkcí“.

Dan také položil otázku, jestli jaderní vývojáři netrpí syndromem „horkých kamen“, protože se v minulosti spálili, a teď odmítají o změnách jenom uvažovat. Thomas a Arjan ale oba upozornili, že neexistuje hardware, který by mohl poskytnout záruky, které Dan požaduje. A Thomas má i popáleniny, kterými to může prokázat:

Bohužel jsem nucen pracovat s více než pěti sty různými variantami zmrvených časovačů, kvůli kterým jenom s nechutí věřím čemukoliv, co slibují výrobci čipů/desek/biosů. Nejsem nervózní kvůli jedinečné zkušenosti s horkými kamny, ale kvůli neustálému vystavení nekončícímu zástupu horkých kamen.

I když diskuze obsahovala mnoho dalších zajímavých analogií, včetně provazů a nožů a kondomů vs. abstinence, neobjevila se (zatím) analogie s auty. Společná myšlenka je zjevně v tom, jestli by volání hodin měla být implementována jako virtuální systémová volání, nebo jestli je potřeba exportovat systémová volání. To pravděpodobně neuspokojí ty, kdo už nějakou chvíli používají vsyscally a stále je z výkonností bolí hlava, a které Dan citoval; není ale nic, co by aplikacím bránilo používat TSC přímo. Takové aplikace musí ale být připraveny na to vyrovnat se s podivným chováním TSC, když na něj narazí.

Ingo Molnár se pokouší objasnit důvody, proč jádro nechce exportovat žádné informace o spolehlivosti: Důvod je to, že jádro nehodlá spolupracovat na praktikách, které nejsou technicky spolehlivé […] Jádro tedy nebude ,signalizovat‘, že lze něco bezpečně použít, když to bezpečně použít nelze. Také ale vidí určitou naději:

Debatu bys ale mohl vyhrát tím, že přijdeš s patchem, který změní gettimeofday tak, aby používala TSC spolehlivým způsobem.

Myslím to vážně – a možná je to možné – ale ještě jsme nezjistili, jak to udělat.

Peter Zijlstra má další řešení problému. Byl by rád, kdyby jádro přikročilo k blokování RDTSC pro uživatelský prostor. Emulací instrukce a logováním jejího používání (a s ní spojené instrukce RDTSCP) by bylo možné najít a změnit programy v uživatelském prostoru:

A až bude většina uživatelského prostoru fungovat dobře, můžeme začít generovat chyby.

Samozřejmě věci bez otevřených kódů by se o sebe musely postarat samy, ale koho to zajímá ;-)

Exportování informací o tom, jestli je gettimeofday() „pomalá“, nebo ne, vypadá jako rozumný počáteční bod. Žádné patche se ohledně toho ještě neobjevily, ale jedná se o poměrně přímočarou záležitost. Může se objevit i něco jako Thomasova vget_tsc_raw(), ale to neuspokojí ty, kteří nejsou spokojeni se současnou výkonností virtuálních systémových volání. Takové aplikace budou prostě muset číst TSC samy a poradit si se vším, co na ně hardware hodí.

Zablokované blokování uspání

napsal Jonathan Corbet, 18. května 2010

Když se Jaderné noviny v dubnu naposledy dívaly na blokování uspání [suspend blockers], vypadalo to, že tato funkce je na své cestě k brzkému začlenění do jádra. Na této cestě možná stále je, ale další diskuze obraz trochu zakalila. Jedná se o relativně malý a obskurní kus kódu, ale osud blokování uspání může mít významné dopady na to, jak se jaderná komunita v budoucnosti vypořádá s externími projekty.

Vzpomeňme, že blokování uspání je spojeno s „oportunistickým uspáváním“, které používá systém Android. V tomto režimu já jádro přepnuto do stavu řízené narkolepsie; usne (a uspí systém) téměř pokaždé, kdy s ním nikdo necloumá. Blokování uspání je způsob, jak s ním cloumat, jedná se o způsob, kterým lze systém udržet vzhůru, když probíhá zpracování něčeho důležitého. Dokud je blokování uspání aktivní, systém se neuspí.

Tento přístup má dva aspekty, které vývojářům Androidu vyhovují. Jeden je, že jsou takto schopni vytěžit lepší správu napájení (delší životnost na baterie) uspáním celého systému, když se nic neděje. Používání běžné správy napájení za běhu nepodává stejné výsledky. Další klíčový bod je, že k oportunistickému uspání může dojít, i když v uživatelském prostoru běží procesy. Pokud není uspání zablokováno, probíhající výpočet není považován za dostatečně důležitý, aby kvůli tomu systém zůstal vzhůru. Toto chování je obrana proti špatně napsaným aplikacím, které by jinak mohly rychle vybít baterie.

Blokování uspání má několik nadšených příznivců. Oportunistické uspávání vypadá trochu jako hack a potřeba vložit blokovače uspání do ovladačů vypadá invazivně – i když bude ve většině jader tato funkce vypnutá, vypadá to jako břemeno pro údržbu. I tak se ale většina vývojářů, kteří se zapojili do diskuze – což zahrnuje téměř každého, kdo pracuje na správě napájení v Linuxu – shodla na tom, že lepší nápad nikdo nemá. Matthew Garret tedy řekl:

Hele, nechci vypadat jako někdo, kdo myslí ve vyjetých kolejích, ale tahle diskuze by byla mnohem přitažlivější, kdyby se našel někdo schopný navrhnout implementaci, která by vyřešila tu sadu požadavků, kterou implementace od Google řeší a kvůli které nikdo nepláče. Jinak bude téměř s jistotou výsledkem to, že bude kód začleněn a budeme s ním muset žít.

Alternativy byly v této diskuzi požadovány několikrát, ale skutečných návrhů bylo málo. Mnoho oponentů blokování uspání se spíše snažilo změnit požadavky – například stanovit povinnost, aby všechny aplikace pro Android byly napsané dobře. Problém je v tom, že když baterie nevydrží dostatečně dlouho, uživatelé to svedou na zařízení (a ne na úžasnou aplikaci, co funguje jako píšťalka na psa). Vývojáři Androidu si tedy musí vybrat mezi do určité míry vynuceným dobrým chováním (například zahozením „otevřeno pro všechny“, což je základní myšlena toho, jak se u Androidu věci dělají), nebo vytvořením dostatečně robustního systému, který bude fungovat i s neideálními aplikacemi.

Vývojáři Androidu zvolili druhý přístup. Přitom vytvořili blokování uspání, což je klíčová součást jejich platformy. Mnoho z ovladačů, které byly vyvinuty pro Android, má podporu pro blokování uspání zabudovanou; v současné podobě je nelze začlenit, když nebudou mít k dispozici API pro blokování uspání. V současnosti je tedy možné buď ovladače držet mimo, nebo z nich vyhackovat blokování uspání a začlenit je bez něj. V prvním případě budeme mít víc kódu mimo strom, v tom druhém budeme mít ve stromě ovladače, které se nepoužívají, netestují a neudržují. Ani jedna z těchto možností není dobrá.

Začlenění blokování uspání by značně zjednodušilo dostat do jádra zbytek kódu; vývojář Androidu Brian Swetland řekl:

S podporou probouzecích zámků v jádře budu schopen udržovat ovladače (za předpokladu, že dodrží požadavky na běžný styl, správnost atd.), které bude možné zaslat do hlavní řady (hurá!) i dodávat na produkčním hardwaru tak, jak jsou (hurá!). Portování dalších na Linuxu založených prostředí na hardware, jako je G1, N1 atd. bude také mnohem jednodušší, z čehož by mohlo mít mnoho lidí radost.

To by nás mohlo dostat ještě blíž k tomu mít možnost vytvořit jádra pro produkční použití a pro různá zařízení s Androidem ze zdrojových kódů hlavní řady; a mě ještě dál od udržování spousty stromů android-něco-2.6.# specifických pro systém na čipu, což není práce, kterou bych opravdu rád dělal.

(„Probouzecí zámky“ [wakelocks] je staré jméno pro blokování uspání.)

Google a vývojáři Androidu si užili spoustu starostí spojených s tím, že se jim nepodařilo pracovat s upstreamem a dostat kód do hlavní řady. Není pochyb, že kód bylo možné zvládnout lépe; kdyby vývojáři Androidu pracovali s jadernou komunitou dříve, než ho začali dodávat v miliónech zařízení, dalo by se možná většině potíží vyhnout. Historii ale teď přepsat nepůjde; to nedokáží ani tajné „instalatérské“ příkazy gitu. Můžeme ale zlepšit budoucí situaci.

Snaha spojená s blokováním uspání vypadá jako skutečný pokus pracovat lépe. Kód nebyl jenom zaslán; prošel více revizemi, než je obvyklé, jak se jeho vývojáři snažili reagovat na komentáře ostatních. Nezačlenit ho by bylo přinejmenším demoralizující. Jestliže vývojová komunita odmítne tento pokus přiblížit Android hlavní řadě, riskuje vznik špatného dojmu. Jestliže kód neakceptujeme, neměli bychom si stěžovat na to, že ho udržují mimo hlavní řadu.

V době psaní tohoto článku je začleňovací okno 2.6.35 otevřené. Co se stane s blokováním uspání, můžeme hádat. Vývojáři správy napájení jsou pro začlenění, ale jiní nadělali spoustu hluku a Linus ještě svoje názory najevo nedal. Těžko tedy říci, jestli se tento dlouhý příběh blíží ke svému konci, nebo ne.

       

Komentáře

[letec]

Když obejmeme každé

prase kolem sebe,

láska bude velká,

jako tahle země.

Tak slibuji, že pomohu

všem prasatům v bídě,

neb nebýt tady prasat,

nebude špek v jídle.

Nice...

[kip]

Začleňovací okno 2.6.53, část první

- je to přehození číslic, nebo jsem něco zaspal?

[Robert Krátký]

Sorry, opraveno.

[Jirka]

Ten Linusuv citat jeste docela zajimave pokracuje.

[Mandarinka]

Raději LESB alokátor.

[geebranz]

User friendly

smallbusinessloansspokane.com