Jaderné noviny - 18. 3. 2009

16. 4. 2009 | Jirka Bourek | Jaderné noviny | 3547×

Aktuální verze jádra: 2.6.29-rc8. Citáty týdne: Andrew Morton, Patrick McHardy, Linus Torvalds. Ts'o: Zpožděná alokace a problém souborů o nulové délce. Garrett: ext4, očekávání aplikací a správa napájení. Jádro má nové logo. Pohled na ftrace. Odkud přišlo 2.6.29.

Obsah

• Aktuální verze jádra: 2.6.29-rc8
• Citáty týdne: Andrew Morton, Patrick McHardy, Linus Torvalds
• Ts'o: Zpožděná alokace a problém souborů o nulové délce
• Garrett: ext4, očekávání aplikací a správa napájení
• Jádro má nové logo
• Pohled na ftrace
• Odkud přišlo 2.6.29

Aktuální verze jádra: 2.6.29-rc8

Současné vývojové jádro 2.6 je stále 2.6.29-rc8 vydané Linusem 12. března. Obsahuje obvyklou sadu oprav a tempo patchů se rozhodně zpomaluje. Ve skutečnosti se zdá, že se stabilizuje do bodu, ve kterém doufám, že se blížíme ke konečnému 2.6.29 a že toto by mohlo být poslední -rc. Uvidíme. Zkrácený changelog je v oznámení, v kompletním changelogu vizte všechny detaily.

V době psaní tohoto článku bylo od vydání 2.6.29-rc8 začleněno téměř 200 sad změn. Většinou jde o opravy, také je zde nové logo maskota, ovladač pro adaptéry Server Engines BladeEngine 2 a ovladač "Dave" pro ethernetové řadiče na deskách Qong FPGA.

Současné stabilní jádro 2.6 je stále 2.6.28.8 vydané 16. března. Ve stejnou dobu byla vydána aktualizace 2.6.27.20. Obě obsahují více než obvykle dlouhý seznam důležitých oprav.

Citáty týdne: Andrew Morton, Patrick McHardy, Linus Torvalds

Bylo to přidáno před pěti nebo šesti lety a nikdy jsem nemusel sníst svůj klobouk.

-- Andrew Morton

S velkým zpožděním jsem konečně vydal první kompletní veřejnou verzi svého kódu nftables (včetně uživatelského prostoru), které jsou míněny jako náhrada pro iptables. Jsou napsány od základu a od iptables se v mnoha ohledech liší jak co se vlastností, tak návrhu týče...

-- Patrick McHardy

Tyhle diskuze už mě opravdu přestaly bavit. Viděl jsem téměř nulové kritické myšlení. Pravděpodobně proto, že každý, kdo o tom měl alespoň nějaké pochyby, jednoduše z diskuze zmizel. Takže tady je můj příspěvek: začněte v malém, začněte znovu a začněte přemýšlet i o jiných záležitostech než jsou jenom kontrolní body.

-- Linus Torvalds se snaží restartovat diskuzi o kontrolních bodech

Ts'o: Zpožděná alokace a problém souborů o nulové délce

Zde je text od Teda Ts'o o ext4, zpožděné alokaci a robustnosti. Jaká je nejlepší cesta kupředu? Prozatím bych Ubuntu hráčům, jejichž systémy neustále padají a kteří by chtěli používat ext4, doporučil připojovací volbu nodelalloc. Nevyčísloval jsem, jaký bude v tomto režimu postih na výkonnosti, ale měla by být lepší než u ext3 a alespoň se tímto způsobem nebudou muset bát, že se jejich soubory v důsledku zpožděné alokace ztratí. Dlouhodobě by autoři aplikací, kteří mají obavy ze ztráty souborů při nečistém vypnutí, měli opravdu používat fsync.

Garrett: ext4, očekávání aplikací a správa napájení

Zde je příspěvek Mattgewa Garretta k debatě o ext4. Nevhodný pro lidi, kterým vadí klení. Milí autoři souborových systémů - vývojáři aplikací rádi zapisují spousty malých souborů, protože to hodně věcí významně zjednodušuje. To je v pořádku, protože čistá výkonnost souborového systému není na seznamu priorit typického vývojáře aplikací vysoko. Odpověď není, 'ehm, všichni byste měli používat sqlite'. Jestliže jediný efektivní způsob, jak používat souborový systém, je použít místo něj databázi, pak to naznačuje, že jste nenapsali souborový systém vhodný pro typického vývojáře aplikací, který si libuje v ukládání věcí do souborů místo do binárních blobů, které končí s úplně odlišnou sadou patologického chování.

Jádro má nové logo

Jak všichni ví, do hlavní řady se v takto pozdní fázi vývojového cyklu začleňují pouze důležité opravy. Jednou z oprav, kterou Linus začlenil 13. března, je SVG obrázek "Tuze", maskota konference linux.conf.au 2009 ve vysokém rozlišení. Tuz, jehož nový domov je v Documentation/logo.svg má světu připomínat problémy, kterým čelí populace tasmánských čertů, a že účastníci linux.conf.au podporují snahu zachránit tento druh před vymřením.

Pohled na ftrace

Linux má poměrně hodně možností sledování, nejvýznamnější je SystemTap, ale konkrétně toto řešení ještě stále není jednoduše použitelné, částečně přinejmenším pro svou závislost na nástrojích a konfiguraci v uživatelském prostoru. Další možnost, která původně přišla z práce na realtimovém Linuxu, je ftrace. Ftrace je uzavřené řešení, které nepotřebuje žádné nástroje nebo podporu z uživatelského prostoru a které je užitečné pro vysledování problémů - nejenom v jádře, ale i v jeho interakci s uživatelským prostorem.

Jméno ftrace pochází ze "sledovač funkcí" [function tracer], což bylo jeho původním účelem, nicméně nyní může dělat víc než to. Byly přidány různé další sledovače, které se mohou dívat na věci jako přepínání kontextu, jak dlouho jsou zakázaná přerušení, jak dlouho trvá, než se úlohy o vysoké prioritě mohou rozběhnout poté, co byly probuzeny atd. Zrození v realtime stromě je patrné na aktuálně dostupných sledovačích, ale ftrace také obsahuje framework pro pluginy, což umožňuje snadné přidání nových sledovačů.

Na vhodně konfigurovaném jádře - s povoleným CONFIG_FUNCTION_TRACER - se k ftrace přistupuje přes souborový systém debug. Ten je typicky připojen takto:

# mount -t debugfs nodev /debug

To vytvoří podadresář /debug/tracing, který se používá k řízení ftrace a pro získání výstupu tohoto nástroje.

Konkrétní sledovač, který použít, se vybírá zápisem do /debug/tracing/current_tracer, potenciálně po zjištění, které sledovače jsou k dispozici, čtením /debug/tracing/available_tracers. Na současném čistém jádře Fedory vypsání dostupných sledovačů vyústí v:

# cat /debug/tracing/available_tracers
power wakeup irqsoff function sysprof sched_switch initcall nop

Sledování je poté zapnuto či vypnuto zápisem do /debug/tracing/tracing_enabled. Sledovač funkcí by se použil takto:

# echo function >/debug/tracing/current_tracer
# echo 1 >/debug/tracing/tracing_enabled
...další příkazy nebo aktivity, které sledovat...
# echo 0 >/debug/tracing/tracing_enabled

To vytvoří sledování všech volaných jaderných funkcí společně s časovou značkou, která umožní jadernému hackerovi zjistit, co se uvnitř jádra děje.

Výstup z ftrace lze číst z jednoho z mnoha souborů v adresáři tracing:

• trace - obsahuje výstup sledování v čitelné podobě

• latency_trace - obsahuje výstup stejného sledování, ale organizován je tak, že lze diagnostikovat problémy s latencí, také v čitelné podobě

• trace_pipe - obsahuje stejný výstup jako trace, ale je míněn k přesměrování do roury příkazu. Na rozdíl od předchozích dvou čtení z toho souboru výstup spotřebovává.

Kruhový buffer používaný ftrace má pevnou velikost (určenou podle souboru buffer_size_kb), takže záznamy v trace a latency_trace se přepisují.

Zde jsou příklady výstupu ze sledování funkcí. Hlavička pomáhá dekódovat různé pole ve sledování. Takto vypadá výstup z trace (značně pozměněný za účelem stručnosti):

# tracer: function
#
#           TASK-PID    CPU#    TIMESTAMP  FUNCTION
#              | |       |          |         |
            bash-3330  [000]   147.799029: sys_open <-syscall_call
            bash-3330  [000]   147.799030: do_sys_open <-sys_open
            bash-3330  [000]   147.799030: getname <-do_sys_open
            bash-3330  [000]   147.799031: kmem_cache_alloc <-getname

Toto je výstup latency_trace (podobně upravený):

# tracer: function
#
function latency trace v1.1.5 on 2.6.29-0.215.rc7.fc11.i586
--------------------------------------------------------------------
 latency: 0 us, #120119/5425477, CPU#0 | (M:desktop VP:0, KP:0, SP:0 HP:0 #P:2)
    -----------------
    | task: -0 (uid:0 nice:0 policy:0 rt_prio:0)
    -----------------

#                  _------=> CPU#            
#                 / _-----=> irqs-off        
#                | / _----=> need-resched    
#                || / _---=> hardirq/softirq 
#                ||| / _--=> preempt-depth   
#                |||| /                      
#                |||||     delay             
#  cmd     pid   ||||| time  |   caller      
#     \   /      |||||   \   |   /           
    bash-3330    0.... 3531221us : sys_open (syscall_call)
    bash-3330    0.... 3531222us : do_sys_open (sys_open)
    bash-3330    0.... 3531222us : getname (do_sys_open)
    bash-3330    0.... 3531223us : kmem_cache_alloc (getname)

Každý řádek v obou výstupních formátech ukazuje jedno volání funkce s jednou úrovní zpětného sledování [backtrace], společně se jménem procesu, ID procesu a informací o tom, na kterém CPU volání proběhlo. Výstup latency_trace také poskytuje informaci o tom, jestli byla zakázána přerušení, jestli bylo vyvoláno přeplánování, jestli funkce běžela v kontextu přerušení a jestli byla zakázaná preempce. Časová značka výstupu latency_trace je relativní vůči začátku sledování, udána je v mikrosekundách; mezera mezi časem a dvojtečkou je pole, které může být nastaveno na '!' nebo '+', aby se přitáhla pozornost na obzvláště dlouhá zpoždění (v tomto příkladu je toto pole vždy prázdné). Hlavička bohužel trochu mate v tom, kam ukazují pole "delay" (zpoždění) a "caller" (volající).

Sysctl kernel.ftrace_enabled určuje, jestli je vstup do funkce zaznamenán jako součást sledování. Zapnout ho lze jedním z těchto dvou příkazů:

# sysctl kernel.ftrace_enabled=1 
nebo 
# echo 1 >/proc/sys/kernel/ftrace_enabled

Bez toho je mnoho sledovačů v podstatě k ničemu.

Půl tuctu různých sledovačů je popsáno v rozsáhlém Documentation/ftrace.txt, který je uložen ve stromě zdrojových kódů jádra. Kromě sledovače funkcí je zde sledovač sched_switch, který sleduje a hlásí přepínání kontextu v jádře a ukazuje přitom probuzení procesů společně s tím, kdy jsou naplánovány. Každý záznam ve sledování obsahuje značku společně s prioritami a stavy dotčených procesů.

Sledovač nop není sledovač, ale lze ho využít k vyčištění kteréhokoliv sledovače, který je zrovna aktivní. V hlavní řadě je sedm dalších sledovačů, které se ještě nedostaly do dokumentace. Kromě nich je ještě více sledovačů, které míří do jádra 2.6.30.

Jsou zde čtyři, které hledají maximální čas strávený v daném stavu a zaznamenávají toto maximum (v trace_max_latency) společně se sledováním funkcí, které byly v tomto stavu zavolány. irqsoff hledá nejdelší čas strávený se zakázanými přerušeními, preemptoff nejdelší čas strávený s vypnutou preempcí. Kombinace těchto dvou dává sledovač preemptirqsoff. Poslední sledovač wakeup zaznamenává nejdelší latenci mezi okamžikem, kdy je proces s nejvyšší prioritou probuzen a kdy je naplánován.

Každý z nich pomáhá omezením množství sledovacích dat, kterými se jaderný hacker musí probrat. Pro jádra, která jsou konfigurována s CONFIG_DYNAMIC_FTRACE je zde další způsob, jak tato data filtrovat. Dynamické ftrace umožňuje uživateli vybrat, které jaderné funkce jsou do sledování buď zahrnuty, nebo z něj vyjmuty. Soubor available_filter_functions vypisuje seznam funkcí, které mohou být filtrovány, přičemž zapsání jména funkce do set_ftrace_filter či set_ftrace_nofilter tyto funkce zahrne nebo vynechá. Seznam lze doplňovat pomocí standardního operátoru přesměrování >> v shellu. Navíc je zde podpora pro divoké znaky [wildcards], takže:

echo 'hrtimer_*' >/debug/tracing/set_ftrace_filter

bude sledovací informace sbírat jenom pro funkce časovače s vysokým rozlišením.

Další sledovače dostupné v jádře hlavní řady (tj. v tom, ze kterého bude 2.6.29), zahrnují:

• power - sleduje přechody mezi napájecími stavy CPU

• function_graph - podobný sledovači funkcí, ale sleduje jak vstup do funkce, tak její opuštění, což umožňuje vygenerování grafu volání.

• sysprof - periodicky (určeno sysprof_sample_period) generuje výpis zásobníku pro běžící proces nebo jaderné vlákno

• initcall - sleduje vstup a opuštění inicializační funkce během bootu systému

• branch - sleduje předpovídání skoků a jejich vykonávání

• hw-branch-tracer - ke sledování vykonávání skoků používá vlastnost Branch Target Stack (BTS) procesorů x86

• mmiotrace - sleduje paměťově mapované I/O

Vytváření čitelného výstupu přímo v jádře nedávno vedlo k tvrdým otázkám od Andrewa Mortona: Proč pořád pokračujeme ve vkládání těchto hezkých vypisovačů a hezkých parserů do jádra? Nebo jinak, jak těžké je pro uživatelský prostor přečíst textový soubor, provést několik základních náhrad a zase ho vypsat? Jiní ale argumentují, že jednoduchost toho dostat přímo od jádra čitelný výpis je přesně to, díky čemu je ftrace tak užitečné.

Andrew argumentuje, že pevný formát je obtížnější zpracovávat [parse] skripty a výstup je pouze anglický. Tvrdí, že nějaký druh API by věci zjednodušilo. Poukázal na výstup latency_trace jako příklad a řekl:

[...] a teď je třeba se zamyslet nad tím, jak by toto rozhraní bývalo bylo navrženo, kdybychom se rozhodli k němu přistupovat něčím chytřejším, než je 'cat'.

Vždyť se na to podívejte. Všechno to zarovnávání sloupců mezerami, zbytečné popisování "us", ta podivná záležitost se symbol(symbol) atd. Navíc by to mělo být více sebepopisující. Teď parser buď musí předpokládat, že druhý znak v "0d..1" je "irqs-off", nebo se musí naučit interpretovat ascii art.

Místo nutnosti mít nějaký nástroj v uživatelském prostoru, který by interpretoval výstup ftrace, může jaderný hacker rychle dostat to, co potřebuje, od samotného jádra. Jak upozornil Ingo Molnár, na cílovém stroji nemusí být prostředí pro překlad, takže přímý výstup ze sledování je užitečný: Soběstačné osazení jádra sledovacími nástroji je klíčový koncept pro použitelnost. Navíc řekl, že výstup je navržen k tomu, aby byl skriptovatelný, ale pokud to není dostatečné, jsou možnosti, jak vygenerovat čistý výstup. Celkově považuje hezké vypisování jádrem za potřebnou vlastnost:

IMO by diskuze o hezkých výpisech v jádře neměla být náboženská, ale technická. Hezké vypisování je nástroj a jako nástroj ho občas lze využít k hloupým účelům a občas k užitečným účelům. Zdá se, že tvrdíš, že dělat to v jádře je vždycky hloupé - a s tím silně nesouhlasím a považuji to za krajní názor - z důvodů naznačených výše.

Volby, na které se Ingo odkazuje, jsou přístupné v souboru trace_options, který vypisuje současné nastavení, když je přečten, změna nastavení je možná zápisem. Formát výstupu řídí volby raw, hex a bin (společně s nějakými dalšími, které rozhodují o tom, která pole jsou vypisována). Tyto volby mohou vygenerovat výstup ve formátu, který může být použitelnější pro nástroje. Možnost získat data ze sledování bez jakéhokoliv nástroje je, přinejmenším někým, považována za velmi důležitou součást ftrace.

Existuje mnohem více voleb a vlastností, které zde nejsou pokryty. Výše zmíněný dokument ftrace.txt je dobrý počáteční bod pro ty, které zajímá více detailů.

Kromě sledovačů, které jsou v současnosti v hlavní řadě, je jich další hrstka, která se připravuje do 2.6.30. To zahrnuje nový sledovač událostí, který umožňuje sledování událostí plánování, zamykání a obsluhy přerušení. Stejně tak je zahrnuto nepřetržité sbírání statistik pro pracovní fronty a predikci skoků.

Ftrace je užitečný nástroj, který může poskytnout skvělé diagnostické informace z běžícího jádra. Není to všeobecný nástroj, stejně tak není vhodný pro lidi, kteří nemají povědomost o vnitřnostech jádra, ale rozhodně má svá využití. Kolem ftrace je v současnosti hodně aktivity, na linux-kernel poletuje mnoho patchů a vylepšení. I když možná přímo neomezuje závist z Dtrace, je to nástroj, který dnes používá mnoho vývojářů.

Odkud přišlo 2.6.29

Tady v redakci Jaderných novin jsme velcí tradicionalisté, a proto, jak se vývojový cyklus 2.6.29 blíží ke svému konci, nás tradice nutí podívat se na to, odkud ten kód přišel.

K 17. březnu bylo do jádra 2.6.29 začleněno 11 610 neslučovacích sad změn. Tyto patche přidaly ohromujících 1 228 000 řádků kódu a dokumentace, odstranily jich 401 000; jádro 2.6.29 bude mít o 827 000 řádků víc než jeho předchůdce. V tomto cyklu se zúčastnilo nějakých 1166 vývojářů. Autor tohoto článku se s pocitem, že je to možná rekord, rozhodl podívat se na předchozí jádra:

Verze	Vývojářů
2.6.22	885
2.6.23	854
2.6.24	950
2.6.25	1124
2.6.26	1027
2.6.27	1022
2.6.28	1078
2.6.29	1166

Zdá se, že je zde jasný trend: jaderná komunita vývojářů se během posledních pár let výrazně zvětšila. Počet zaměstnavatelů, kteří za těmito vývojáři stojí (175), se zvětšil o málo, ale kvůli nejistotě platnosti spojení zaměstnavatele s vývojářem je vhodné toto číslo nebrat příliš vážně. Stačí říct, že je tu pár firem, které podporují vývoj jádra.

Zde jsou statistiky jednotlivých vývojářů:

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

Podle sad změn Chris Mason 671 5,8 % Takashi Iwai 173 1,5 % Jaswinder Singh Rajput 158 1,4 % Stephen Hemminger 154 1,3 % Mike Frysinger 150 1,3 % Christoph Hellwig 143 1,2 % Ben Dooks 142 1,2 % Alexey Dobriyan 138 1,2 % Ingo Molnár 133 1,1 % Rusty Russell 127 1,1 % Steven Rostedt 110 0,9 % Mauro Carvalho Chehab 109 0,9 % Mark Brown 108 0,9 % Sam Ravnborg 108 0,9 % David S. Miller 107 0,9 % Greg Kroah-Hartman 105 0,9 % Harvey Harrison 101 0,9 % David Howells 100 0,9 % Russell King 93 0,8 % Paul Mundt 87 0,7 %

Podle změněných řádků Greg Kroah-Hartman 280883 20,8 % Luis R. Rodriguez 71604 5,3 % Chris Mason 69935 5,2 % Daniel Krueger 56534 4,2 % David Kiliani 41371 3,1 % David Daney 18767 1,4 % Solomon Peachy 17386 1,3 % Robert Love 15262 1,1 % Sujith 14703 1,1 % Inaky Perez-Gonzalez 14388 1,1 % David S. Miller 13422 1,0 % Jesse Barnes 13036 1,0 % Christoph Hellwig 12548 0,9 % Michael Hennerich 12334 0,9 % Subbu Seetharaman 12285 0,9 % Jaswinder Singh Rajput 11651 0,9 % Rusty Russell 10878 0,8 % Ben Dooks 10809 0,8 % David Schleef 10325 0,8 % Mark Brown 9945 0,7 %

Chris Mason se na vrchol v kategorii "podle sad změn" dostal díky začlenění Btrfs. To je jistě významný kus kódu, ale počet sad změn je zde tak vysoký, protože byla začleněna kompletní vývojová historie Btrfs. Vidíme zde tedy o něco více než tři měsíce práce. Takashi Iwai udělal spoustu práce v subsystému ALSA, konkrétně na ovladači Intel HDA. Jaswinder Singh Rajput přispěl mnoha pročišťovacími patchi. Práce Stephen Hemmingera sestávala hlavně ze změny API síťových ovladačů a poté opravy dlouhého seznamu rozbitých ovladačů. A Michael Frysinger přispěl mnoha změnami v architektuře Blackfin.

Pokud se podíváme na řazení podle počtu změněných řádků, výsledný obraz se trochu liší. Jako v 2.6.28 Greg Kroah-Hartman nacpal do stromu -staging velké množství svinstva (jeho výraz); tento kód neobsahuje v gitovém repozitáři původní informace o autorovi (i když ocenění v kódu samozřejmě zůstávají). Luis Rodriguez udělal spoustu práce na bezdrátových ovladačích Atheros a subsystému cfg80211; velká část jeho práce je spojena s podporou regulace bezdrátových zařízení. Daniel Krueger svého místa v žebříčku dosáhl zasláním jediného patche: síťového stacku Systec Electronic openPOWERLINK. David Kiliani je další jednopatchový zázrak; jeho je ovladač pro karty Meilhaus ME-IDS pro sběr dat. Danielovy a Davidovy patche přešly do stromu -staging, přes -staging se tedy do hlavní řady dostala práce tří z pěti největších přispěvatelů kódu.

Statistiky zaměstnavatelů spojených s vývojáři vypadají takto:

Nejaktivnější zaměstnavatelé v 2.6.29

Podle sad změn (žádný) 1612 13,9 % (neznámý) 1378 11,9 % Red Hat 1229 10,6 % Oracle 992 8,5 % IBM 749 6,5 % Intel 686 5,9 % Novell 632 5,4 % (konzultant) 370 3,2 % Analog Devices 282 2,4 % Fujitsu 212 1,8 % (školství) 204 1,8 % Renesas Technology 165 1,4 % Nokia 163 1,4 % Vyatta 154 1,3 % Parallels 149 1,3 % Simtec 138 1,2 % Atheros Communications 131 1,1 % AMD 130 1,1 % Wolfson Microelectronics 104 0,9 % SGI 100 0,9 %

Podle změněných řádků Novell 306183 22,7 % (neznámý) 197224 14,6 % Atheros Communications 96202 7,1 % Oracle 93846 7,0 % (žádný) 92811 6,9 % Red Hat 77087 5,7 % Intel 62265 4,6 % SYS TEC electronic GmbH 56534 4,2 % Analog Devices 44659 3,3 % IBM 40560 3,0 % (konzultant) 28983 2,1 % Cavium Networks 18767 1,4 % Renesas Technology 16946 1,3 % Nokia 11951 0,9 % Simtec 10886 0,8 % Broadcom 10314 0,8 % Wolfson Microelectronics 10147 0,8 % Freescale 8520 0,6 % Chelsio 7738 0,6 % QLogic 7322 0,5 %

Čísla u zaměstnavatelů se mezi jednotlivými verzemi příliš nemění; většinou se objevují stejné společnosti. Nově se na seznam dostaly Vyatta (podporuje práci Stephena Hemmingera) a některé firmy (Simtec, SYS TEC, Cavium Networks), které dodaly podporu pro své vlastní produkty.

Počet patchů se značkou Revidováno-kým zůstává relativně malý - méně než 5 % ze všech. Nejvíce ocenění revidovatelé jsou tentokrát:

Vývojáři s největším počtem revizí
James Morris	64	20,2 %
Dave Chinner	51	16,1 %
Christoph Hellwig	39	12,3 %
Andrew Morton	14	4,4 %
Eric Sandeen	12	3,8 %
Daisuke Nishimura	11	3,5 %
KOSAKI Motohiro	10	3,2 %
Matthew Wilcox	8	2,5 %
WANG Cong	7	2,2 %
Zhu, Yi	5	1,6 %
KAMEZAWA Hiroyuki	5	1,6 %
Eric Anholt	4	1,3 %
Pekka Enberg	4	1,3 %
Tomas Winkler	4	1,3 %
Paul Menage	4	1,3 %
Mike Christie	4	1,3 %
Grant Grundler	4	1,3 %

Tato čísla jsou velmi ovlivněna tím, jak je hlášeno revidování; rozhodně se reviduje víc, než je zde vidět. Totéž platí pro ocenění za hlášení chyb a testování. Pro 2.6.29 jsou tato čísla takováto:

Nejvíce ocenění ohlašovatelé a testeři v 2.6.29

Ocenění za ohlášeno-kým Randy Dunlap 13 3,8 % Ingo Molnar 7 2,0 % Li Zefan 6 1,7 % Alexander Beregalov 5 1,5 % Stephen Rothwell 5 1,5 % Stefan Richter 4 1,2 % Johannes Berg 4 1,2 % Eric Sesterhenn 4 1,2 % Kamalesh Babulal 4 1,2 % Larry Finger 3 0,9 % Linus Torvalds 3 0,9 % Andrew Morton 3 0,9 % Guennadi Liakhovetski 3 0,9 % Huang Ying 3 0,9 % Daisuke Nishimura 3 0,9 % Meelis Roos 3 0,9 % Geert Uytterhoeven 3 0,9 %

Ocenění za testováno-kým: Hin-Tak Leung 14 5,2 % Mike Frysinger 7 2,6 % Larry Finger 7 2,6 % Ingo Molnar 6 2,2 % Herton Ronaldo Krzesinski 6 2,2 % Li Zefan 5 1,9 % Daisuke Nishimura 4 1,5 % KAMEZAWA Hiroyuki 4 1,5 % Andrew Patterson 4 1,5 % Meelis Roos 4 1,5 % KOSAKI Motohiro 3 1,1 % Stephen Gildea 3 1,1 % Robert Jarzmik 3 1,1 % Serge Hallyn 3 1,1 % Eric Sesterhenn 3 1,1 %

Ve shrnutí byl vývojový cyklus 2.6.29 jedním z nejaktivnějších v historii, do jádra si našlo cestu ohromné množství kódu a padl rekord v počtu spolupracujících vývojářů. Komunita vývojářů by si zaslouženě mohla dát po takové práci přestávku, ale vývoj jádra, zdá se, nikdy nepřestává. V současnosti již spousta kódu čeká na otevření začleňovacího okna 2.6.30, ve kterém celý cyklus začne nanovo.

(Jako vždycky díky Gregu Kroah-Hartmanovi za pomoc při sestavování těchto statistik.)

       

Komentáře

[Salutis]

Dobrá práca, tieto Jadrové noviny. Díky.

[YYY]

Dekuju za pekny clanek. Ten ftrace vypada moc dobre.