Jaderné noviny – 5. 5. 2010

18. 5. 2010 | Jirka Bourek

Články - Jaderné noviny – 5. 5. 2010  

Aktuální verze jádra: 2.6.34-rc6. Citáty týdne: Andrew Morton, Red Hat Enterprise Linux Team, Ted Ts'o, David Miller. Drsný restart pro kontrolní body. Zmenšování sledovacích bodů. Cleancache a frontswap. Přepracování pm_qos. Statistiky vývoje jádra pro 2.6.34 a další. Vyhlídky do budoucna.

Obsah

• Aktuální verze jádra: 2.6.34-rc6
• Citáty týdne: Andrew Morton, Red Hat Enterprise Linux Team, Ted Ts'o, David Miller
• Drsný restart pro kontrolní body
• Zmenšování sledovacích bodů
• Cleancache a frontswap
• Přepracování pm_qos
• Statistiky vývoje jádra pro 2.6.34 a další
  • Vyhlídky do budoucna

Aktuální verze jádra: 2.6.34-rc6

Současné vývojové jádro je stále 2.6.34-rc6 vydané 29. dubna. Tato předverze obsahuje spoustu oprav doplněnou balónovým ovladačem VMware (krátce zmíněný zde začátkem dubna) a ovladačem ipeth, který zajišťuje řetězení USB na iPhone. Zkrácený changelog je v oznámení, kompletní changelog obsahuje všechny detaily.

Stabilní aktualizace se za minulý týden neobjevily.

Citáty týdne: Andrew Morton, Red Hat Enterprise Linux Team, Ted Ts'o, David Miller

Jestliže jsi používal dva procesy, s klidem bych obvinil plánovač. Protože obvinit plánovač kvůli PodivnéSračceKteráSeRozbila je obvykle správně.

-- Andrew Morton

Jádro Red Hat Enterprise Linux 6 obsahuje mnohá zlepšení subsystémů pocházejících z jádra 2.6.34 stejně jako z jeho předchůdců. Výsledkem je, že jádro Red Hat Enterprise Linux 6 nelze jednoduše označit jako jednu konkrétní verzi z upstreamu, spíše se jedná o hybrid několika posledních verzí. A vzhledem k tomu, že Red Hat poskytuje pravidelné aktualizace během životního cyklu produktu, očekáváme, že jádro Red Hat Enterprise Linux 6 bude obsahovat i vybrané vlastnosti z budoucích jader z upstreamu, které ještě nebyly vyvinuty.

-- Red Hat Enterprise Linux Team

Můj problém spočívá v tom, že mám neuvěřitelnou spoustu práce a již jsem Ubuntu prokázal obrovskou službu tím, že jsem strávil deset minut rychlým zkoumáním. Nelze se spolehnout na to, že není potřeba najímat zkušeného vývojáře jádra, protože vývojáři v upstreamu budou na rozkaz okamžitě skákat skrz hořící obruče kvůli blížící se deadline LTS; to se Ubuntu musí naučit.

…

Další věc, kterou se Ubuntu musí naučit: Jak platit svým lidem dost peněz a jak jim nechat dostatek času na práci na záležitostech v upstreamu, aby – jakmile získají za pár šušníků od Ubuntu dost zkušeností a reputaci v open source komunitě – neskákali přes palubu ke Googlu nebo Red Hatu :-)

Na druhou stranu, když se management v Ubuntu nepoučí, tak taky OK. Google shání lidi :-)

-- Ted Ts'o

Povídání o vysokoúrovňovém návrhu obvykle nepřitáhne velkou pozornost a často se s tím nelze nikam dostat. Dej nám příklad implementace, abychom měli po ruce něco konkrétního, do čeho se dá zakousnout.

-- David Miller

Drsný restart pro kontrolní body

napsal Jonathan Corbet, 5. května 2010

V únoru byla sada patchů kontrolních bodů/restartu [checkpoint/restart] zaslána do jaderné e-mailové konference s požadavkem na začlenění do stromu -mm. To bylo těsně před začleňovacím oknem 2.6.34, takže pro revize bylo k dispozici jenom omezené množství pozornosti vývojářů. Tenkrát Andrew Morton navrhl:

Navrhl bych počkat na dobu těsně po 2.6.34-rc1, poté, prosím, pošlete všechny patche do konference a dáme se do práce.

Vývojáři kontrolních bodů/restartu zaslali patche v březnu s relativně malou odezvou. Těsně před začleňovacím oknem 2.6.35 to celé zaslali znovu jako sérii 100 patchů. Není překvapení, že se objevily stížnosti na tak masivní e-maily, ale je tu i další – ještě nepříznivější důsledek: Na patche se nikdo nedívá.

To také není překvapení. Počet vývojářů, kteří mají čas na revize patchů, je nedostačující i za nejlepších okolností, a s blížícím se začleňovacím oknem je to horší. A i ten nejotrlejší revidovatel bude poněkud zastrašen sérií 100 patchů, která sahá do téměř všech vnitřních částí jádra. Většina z nich se rozhodne, že mají na práci něco důležitého někde jinde.

Kontrolní body/restart tedy pravděpodobně budou pozdrženy, než uplyne další začleňovací okno. Poté, pokud se vrátí v trochu snesitelnějších kusech, se budou vývojáři moci opravdu pustit do práce.

Zmenšování sledovacích bodů

napsal Jonathan Corbet, 5. května 2010

Podpora sledování v Linuxu za posledních pár let udělala velký pokrok. Jednou z klíčových vlastností vyspělého sledovacího systému je však dlouhý seznam dobře definovaných a dobře dokumentovaných sledovacích bodů [tracepoint], které správci systému umožňují zaháčkovat se do událostí v jádře bez znalostí jaderného kódu samotného. Sledovací body v jádře postupně přibývají, ale jak si všiml Steven Rostedt, je tu problém: Každý sledovací bod přidává mezi 1 kB a 5 kB k velikosti jádra. Když začneme přemýšlet o přidání stovky (či více) sledovacích bodů, režie naroste.

Stevena je možné z toho vinit stejně jako kohokoliv jiného, takže se rozhodl to napravit. Jeho patch o devíti částech přesouvá některé informace tak, aby byly sdíleny, a odstraňuje nepotřebné věci; výsledkem je zredukování velikosti jeho jádra o 100 kB. Není potřeba říkat, že to se vyplatí ušetřit; zvyšuje se tím pravděpodobnost, že budou sledovací body povoleny na produkčních jádrech.

Samozřejmě většina z nás bude muset Stevenovi věřit, že ty patche dávají smysl; jsou napsány v tom zvláštním dialektu maker preprocesoru C, kterých se pouhý jaderný hacker bojí dotknout. Většina z nás tedy asi ráda přijme úsporu paměti, ale nebude se příliš podrobně dívat na to, jak jí bylo dosaženo.

Cleancache a frontswap

napsal Jonathan Corbet, 4. května 2010

Patch přechodné paměti od Dana Magenheimera zde byl zkoumán loni v červenci. Tento patch vytváří speciální třídu paměti, která není přímo přístupná zbytku jádra, což umožní používat nějaké triky. Od té doby se přechodná paměť zdánlivě vytratila z dohledu – přinejmenším doteď. Dan je zpět s párem nových abstrakcí nazvaných „Cleancache“ a „Frontswap“ – každá z nich obaluje část toho, co dělá přechodná paměť.

Z těch dvou je méně kontroverzní cleancache. Dan ji popisuje jako cache čistých stránek – obětních beránků s granularitou na jednotlivé stránky, což by pro většinu čtenářů Jaderných novin mělo být jasné a srozumitelné. Pro ty, kteří potřebují více slov: Cleancache poskytuje místo, kam může jádro vložit stránky, které si může dovolit ztratit, ale které by si rádo nechalo, pokud to bude možné. Klasickým příkladem jsou čisté stránky obsahující data souborů, které lze v případě potřeby získat z disku. Jádro takové stránky může zahodit bez ztráty dat, ale věci se zpomalí, pokud bude potřeba v blízké budoucnosti stránku opět načítat.

V takových situacích by jádro místo zahazování mohlo vložit stránku do systému Cleancache voláním:

int cleancache_put_page(struct page *page);

Někdy v budoucnu, pokud je stránka zapotřebí, ji lze získat pomocí:

int cleancache_get_page(struct page *page);

Klíčový bod je to, že nikdy není garantováno, že cleancache_get_page() opravdu uspěje a stránku vrátí. Kód Cleancache (nebo jakýkoliv mechanismus, který za ním sedí) může stránku kdykoliv zahodit, pokud potřebuje paměť k nějakému jinému účelu. Uživatelé Cleancache tedy musí být připraveni na to sáhnout si na fyzické úložiště, pokud volání cleancache_get_page() selže.

Dokud Cleancache drží stránku, může s ní dělat zajímavé věci: Stránky s duplicitním obsahem nejsou vzácnost, obzvláště u virtualizace; mnoho stránek často obsahuje jenom nuly. Úložiště za Cleancache může takové duplikace detekovat a ukládat jedinou kopii. Možná je i komprese uložených stránek; v současnosti se pracuje na implementaci ramzswap (CompCache) jako backendu pro Cleancache. Také by mohlo být možné použít Cleancache jako součást cache na disku bez pohyblivých částí před běžným rotujícím diskem.

Danovy patche zahrnují háčky u běžných souborových systémů, aby Cleancache používaly automaticky.

Druhou stranou rovnice je Frontswap; na rozdíl od Cleancache má Frontswap pracovat s nečistými stránkami, kterých by se jádro rádo zbavilo. Opět je zde rozhraní pro vkládání a vyjímání stránek do a ze systému:

int frontswap_put_page(struct page *page);
int frontswap_get_page(struct page *page);

Pravidla jsou tentokrát ale trochu odlišná: Frontswap nemusí přijmout stránky, které jsou do něj vkládány (takže frontswap_put_page() může selhat), ale je garantováno, že každá stránka, která je přijata, bude k dispozici, když ji jádro bude chtít zpátky.

Jako Cleancache může i Frontswap použít nějaké triky, aby trochu roztáhl dostupnou paměť. Skutečným účelem tohoto mechanismu je ale podle všeho snaha, aby hypervizor mohl rychle reagovat na špičky využívání paměti ve virtualizovaných hostech. Dan to řekl takto:

Frontswap hezky slouží jako nouzový bezpečnostní ventil v případě, že se host vzdal (příliš) mnoha paměti pomocí balónového ovladače a najednou ji nečekaně potřebuje tak urgentně, že to není možné zařídit balónem.

Revidovatelé byli k tomuto mechanismu skeptičtější. Některým to připadá jako obcházení nedostatků balónového ovladače, který je již nyní pověřen implementací rozhodnutí hypervizoru o tom, kolik paměti lze zpřístupnit hostovi. V takovém případě se zdá, že by byl lepší přístup oprava ovladače. Dan odpověděl, že balónové ovladače nemohou rychle reagovat na potřebu paměti a regulace paměti hosta balónovým ovladačem může vést ke swapovací bouři. To je zjevně skutečný problém, na který se naráží na virtualizovaných systémech v produkčním prostředí. Pokud by místo toho hypervizor udržoval fond stránek pro Frontswap, mohl by je rychle zpřístupnit, když bude potřeba, což by omezilo výkonnostní problémy spojené s pamětí.

Krom toho si Avi Kivity stěžoval, že když je hostům pomocí Frontswap přidělena nějaká paměť, není možné jim ji odebrat, dokud ji budou držet. Vzhledem k tomu, že operační systémy bývají napsány tak, aby využívaly veškerou paměť, kterou mají k dispozici, zdá se možné, že by se paměť pro Frontswap rychle zaplnila a zůstala plná, takže by hypervizor zůstal bez paměti a spravoval by stránky, kterých se nemůže zbavit. Avimu se také nelíbí synchronní povaha jedna-stránka-naráz u API Frontswap. Dan zde reagoval tak, že kvóty pro jednotlivé hosty jim zabrání, aby spotřebovaly příliš mnoho prostoru ve Frontswap a že API se lépe hodí k řešení problému.

Bez ohledu na stížnosti se zdá, že Cleancache a Frontswap se vcelku široce používají; dodávají se v OpenSUSE 11.2, VM virtualizačním produktu od Oracle a se Xenem. Toto distribuování rozhodně napíná pravidlo „nejprve do upstreamu“ do krajnosti, ale také ukazuje, že tyto vlastnosti mají reálné využití. Vzhledem k tomu, že tyto patche nejsou výrazně rušivé a že dané vlastnosti nemají žádné náklady, když se nepoužívají, zdá se, že se přibližně v této podobě dřív či později dostanou do hlavní řady.

Přepracování pm_qos

napsal Jonathan Corbet, 4. května 2010

Pro omezení spotřeby našich strojů se čím dál tím více používá agresivní správa napájení. Někdy ale může správa napájení způsobit nadměrné latence a tak bránit v práci, kterou je potřeba udělat. Jeden ze způsobů, kterými se lze vyhnout problémům, je dát částem jádra citlivým na latenci možnost vyjádřit své potřeby, které potom kód správy napájení může vzít v potaz. Sledování těchto požadavků je úkolem kódu pm_qos („kvalita služby správy napájení“). Je dost možné, že API pm_qos se v 2.6.35 výrazně změní.

Kód pm_qos v současnosti definuje tři parametry kvality služby, pro které lze specifikovat potřeby: Jde o latenci CPU (PM_QOS_CPU_DMA_LATENCY), latenci při reakci na síť (PM_QOS_NETWORK_LATENCY) a propustnost sítě (PM_QOS_NETWORK_THROUGHPUT); první dva se udávají v mikrosekundách, propustnost v kB/s. V současnosti požadavky na latenci dodržuje subsystém cpuidle a požadavky na latenci sítě dodržuje pouze vrstva mac80211. Jakýkoli požadavek na minimální propustnost sítě v současných jádrech nedopadne na úrodnou půdu; vzhledem k tomu, jak efektivně autor článku žádá svého ISP o lepší služby, se dá předpokládat, že ignorováním požadavků na propustnost programátoři síťování jednoduše šetří zbytečnou práci.

API pro specifikaci parametrů kvality služby je:

#include <linux/pm_qos_params.h>

int pm_qos_add_requirement(int qos, char *name, s32 value);
int pm_qos_update_requirement(int qos, char *name, s32 value);
void pm_qos_remove_requirement(int qos, char *name);

U všech funkcí platí, že qos je jeden z parametrů uvedených výše, name identifikuje subsystém, který specifikoval požadavek a value je nový požadavek. Řetězec name se používá pro identifikaci specifického požadavku v pm_qos_update_requirement() a pm_qos_remove_requirement(); musí se shodovat s hodnotou, která byla zadána, když byl požadavek poprvé přidán.

Jaderný kód, který se může rozhodovat o něčem, co ovlivňuje kvalitu služby, by současným požadavkům měl věnovat pozornost. Jsou dvě možnosti, jak to udělat: První je prostě se pm_qos zeptat, jaký je aktuálně nejpřísnější požadavek:

int pm_qos_requirement(int qos);

Alternativa je registrovat notifikátor, který je zavolán pokaždé, když se daný požadavek změní voláním:

int pm_qos_add_notifier(int qos, struct notifier_block *notifier);
int pm_qos_remove_notifier(int qos, struct notifier_block *notifier);

Toto API je již nějakou dobu k dispozici, ale v jádře se příliš nepoužívá. Jedna stížnost byla, že používání řetězců k identifikaci požadavků vede k neefektivnímu chování: Změna požadavků znamená procházení seznamu a porovnávání spousty řetězců. Požadavky jsou ze své povahy specifikovány kódem citlivým na latenci, takže dává smysl, aby byl tento proces co nejrychlejší. Používání libovolných řetězců také otevírá vzdálenou možnost zmatku v případě, že dva vývojáři náhodou použijí stejné jméno.

V reakci na tyto problémy hacker pm_qos Mark Gross navrhl nějaké změny API. V nové verzi se z „requirements“ (požadavků) stávají „requests“ (potřeby) a odstraňuje se identifikace řetězci. Nové API pro specifikaci požadavků potřeb je:

struct pm_qos_request_list *pm_qos_add_request(int qos, s32 value);
void pm_qos_update_request(struct pm_qos_request_list *pm_qos_req,
                           s32 new_value);
void pm_qos_remove_request(struct pm_qos_request_list *pm_qos_req);

Struktura pm_qos_request_list je pro volající neprůhledná; slouží pouze jako manipulátor identifikující specifický požadavek. Změny a odstranění nyní probíhají bez procházení seznamu a bez porovnávání řetězců. Z pm_qos_requirement() se stává pm_qos_request(), ale API se jinak nemění.

Tato změna nevypadá kontroverzně a měla by řešit kritiku, které čelilo stávající API. Pokud se nestane něco překvapivého, nové API bude pravděpodobně začleněno do 2.6.35.

Statistiky vývoje jádra pro 2.6.34 a další

napsal Jonathan Corbet, 4. května 2010

V době psaní tohoto článku je aktuální předverze jádra 2.6.34-rc6. Před finální verzí pravděpodobně vyjde ještě několik předverzí, ale počet změn v nich by měl být malý. Jinými slovy je 2.6.34 blízko ke své finální podobě, takže se můžeme podívat na to, co se v tomto vývojovém cyklu dostalo dovnitř. V několika ohledech je 2.6.34 neobvyklé jádro.

Toto jádro má za sebou příspěvek 9100 neslučovacích sad změn od něco přes 1100 vývojářů. Tím je o trochu menší, než jeho předchůdci, což je vidět z této tabulky:

Jádro	Patchů	Vývojářů
2.6.29	11 600	1 170
2.6.30	11 700	1 130
2.6.31	10 600	1 150
2.6.32	10 800	1 230
2.6.33	10 500	1 150
2.6.34	9 100	1 110

Účast vývojářů na tomto vývojovém cyklu byla o něco menší než obvykle, ale nijak významně. Zdá se ale, že tito vývojáři toho měli tentokrát na práci o něco méně. Jeden by mohl být v pokušení připsat to na vrub kratšímu začleňovacímu oknu na začátku tohoto cyklu, ale fakt je, že Linus nechal nový materiál projít i po 2.6.34-rc1, takže efektivně bylo začleňovací okno stejně dlouhé jako vždycky.

Seznam nejaktivnějších vývojářů naznačuje, že se možná děje něco jiného: Mnoho vývojářů, kteří tradičně do jádra přidávají velké množství kódu, tentokrát tiše sedělo.

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

Podle sad změn Sage Weil 212 2,3 % Joe Perches 169 1,9 % Paul Mundt 153 1,7 % Uwe Kleine-König 109 1,2 % Mark Brown 102 1,1 % Ben Dooks 96 1,1 % Rafał Miłecki 88 1,0 % Dan Carpenter 84 0,9 % Alex Deucher 83 0,9 % H Hartley Sweeten 80 0,9 % Christoph Hellwig 75 0,8 % Johannes Berg 74 0,8 % Arnaldo Carvalho de Melo 72 0,8 % Bartlomiej Zolnierkiewicz 64 0,7 % David S. Miller 63 0,7 % Magnus Damm 63 0,7 %

Podle změněných řádek Sage Weil 30233 4,1 % Vladislav Zolotarov 23119 3,2 % Jarod Wilson 19689 2,7 % Mark Brown 18513 2,5 % Dimitris Michailidis 13919 1,9 % Manuel Lauss 11831 1,6 % Jörn Engel 10810 1,5 % Kukjin Kim 10142 1,4 % Alex Deucher 9785 1,3 % Amit Kumar Salecha 9391 1,3 % Michael Chan 9336 1,3 % Joe Perches 8738 1,2 % Paul Mundt 8438 1,2 % Haojian Zhuang 8403 1,1 % Magnus Damm 8320 1,1 % Matthias Benesch 7739 1,1 %

Sage Weil vyskočil na první místo v obou žebříčcích díky začlenění souborového systému Ceph a následnému opravování chyb. Joe Perches je novým králem triviálních patchů; jeho práce zahrnuje spoustu oprav podle checkpatch, přepracování vypisování v síťových ovladačích a ne méně než 37 patchů implementujících poněkud opožděné pročištění ovladače pro floppy mechaniky. Práce Paula Mundta téměř exkluzivně spadá do jeho role správce architektury Super-H. Uwe Kleine-König většinou pracuje na kódu architektury ARM a Mark Brown je nadále silným zdrojem kódu zvukových ovladačů a embedded procesorů.

Na straně „změněných řádek“ Vladislav Zolotarov přispěl pouze devíti patchi, všechny v ovladači Broadcom NetXtreme II – ty ale obsahovaly rozsáhlou náhradu firmwaru ve stromě. Počet patchů od Jaroda Wilsona je ještě menší – tři patche; přispěl ovladačem Broadcom Crystal HD do stromu staging. Dimitris Michailidis si své místo zasloužil novým ethernetovým ovladačem pro Chelsio Communications T4.

Jako přispěvatelé do jádra 2.6.34 bylo identifikováno těsně nad 180 zaměstnavatelů – téměř stejně jako u 2.6.33. Ve shrnutí jádra 2.6.33 autor článku hádal, že pozice Red Hatu jako největšího přispěvatele může být ohrožena; podívejme se, jestli se tato předpověď v 2.6.34 splnila:

Nejaktivnější zaměstnavatelé 2.6.34

Podle sad změn (žádný) 1455 16,0 % (neznámý) 959 10,5 % Red Hat 934 10,3 % Intel 472 5,2 % IBM 354 3,9 % Novell 329 3,6 % (konzultant) 274 3,0 % Nokia 248 2,7 % New Dream Network 237 2,6 % Renesas Technology 188 2,1 % Texas Instruments 180 2,0 % Pengutronix 154 1,7 % Oracle 144 1,6 % HP 128 1,4 % (školství) 125 1,4 % Analog Devices 123 1,4 % AMD 121 1,3 % Fujitsu 121 1,3 % Marvell 120 1,3 % Wolfson Microelectronics 101 1,1 %

Podle změněných řádek Red Hat 75235 10,3 % (žádný) 75160 10,3 % (neznámý) 67541 9,2 % Broadcom 56595 7,7 % Intel 33175 4,5 % New Dream Network 31501 4,3 % (konzultant) 29140 4,0 % Novell 24217 3,3 % Wolfson Microelectronics 20660 2,8 % Renesas Technology 16205 2,2 % Chelsio 13937 1,9 % IBM 13618 1,9 % QLogic 13182 1,8 % MSC Vertriebs GmbH 12545 1,7 % Samsung 12224 1,7 % Marvell 11914 1,6 % Texas Instruments 11228 1,5 % Analog Devices 11047 1,5 % AMD 10894 1,5 % Nokia 10217 1,4 %

Při pohledu na absolutní čísla se příspěvky od Red Hatu od 2.6.33 výrazně zmenšily z 1223 sad změn na 934. Všichni ostatní klesli ještě více; počet sad změn od Intelu byl méně než poloviční. Red Hat tedy pevně zůstává na čelní příčce. Mnoho dalších firem na seznamu není žádným překvapením, ale čtenářům nechť je odpuštěno, když se podivují nad New Dream Network; to je firma spoluzaložená vývojářem Ceph Sagem Weilem.

Pokud se podíváme na neautorské podpisy, získáme pohled na nejaktivnější vrátné jádra. Zde jsou, tady se žádná překvapení nekonají.

Nejvíce neautorských podpisů
Podle vývojáře David S. Miller 1034 13,0 % Greg Kroah-Hartman 780 9,8 % Andrew Morton 546 6,9 % John W. Linville 546 6,9 % Ingo Molnár 348 4,4 % Mauro Carvalho Chehab 330 4,2 % James Bottomley 244 3,1 % Dave Airlie 150 1,9 % Ralf Baechle 144 1,8 % H. Peter Anvin 141 1,8 %	Podle zaměstnavatele Red Hat 2865 36,1 % Novell 1293 16,3 % Intel 565 7,1 % Google 547 6,9 % (žádný) 365 4,6 % IBM 289 3,6 % (konzultant) 194 2,4 % Wind River 145 1,8 % Atomide 130 1,6 % Oracle 128 1,6 %

Před deseti vývojovými cykly (2.6.24) byl Andrew Morton nejaktivnější vrátný a podepsal téměř 1700 patchů. Jeho role správce subsystému poslední záchrany během let poněkud vymizela s tím, jak víc správců začalo spravovat své vlastní repozitáře a zasílat patche přímo Linusovi. Když už mluvíme o Linusovi, nejenom že se nedostal do seznamu výše, ale nebyl ani blízko: Jeho 71 popisů ho umisťuje na 22. místo. Umístění Davea Airlieho naznačuje, kolik se toho děje v oblasti grafik.

Přes 50 % patchů do hlavní řady jádra opět proudí pod rukama někoho, kdo je zaměstnán v Red Hatu nebo Novellu.

Vyhlídky do budoucna

V době psaní tohoto článku se otevření začleňovacího okna 2.6.35 dá očekávat někdy v následujících 1-3 týdnech. Podle stanovených pravidel vývojového procesu jádra by většina kódu mířená k tomuto začlenění měla již být ve stromě linux-next. S ohledem na to autor článku stáhl linux-next ze 4. května a podíval se, co se chystá. V současnosti je v tomto stromě 5144 neslučovacích sad změn reprezentujících 758 vývojářů. Největší přispěvatelé jsou:

Nejaktivnější vývojáři v linux-next
Podle sad změn Mauro Carvalho Chehab 245 4,8 % Eric Paris 103 2,0 % Alexander Graf 84 1,6 % Johannes Berg 59 1,1 % Juuso Oikarinen 59 1,1 % Jean-François Moine 58 1,1 % Luis R. Rodriguez 58 1,1 % Greg Kroah-Hartman 52 1,0 % Sujith 52 1,0 % Dan Carpenter 51 1,0 %	Podle změnených řádek Mauro Carvalho Chehab 28743 6,2 % Eliot Blennerhassett 18429 4,0 % Bob Beers 11703 2,5 % Luis R. Rodriguez 10507 2,3 % Steve Wise 9447 2,0 % Viresh Kumar 9426 2,0 % Jason Wessel 8739 1,9 % Sjur Braendeland 8685 1,9 % Stephen Rothwell 7908 1,7 % Matthias Benesch 7739 1,7 %

Mauro Carvalho Chehab měl rušný vývojový cyklus; kromě velkého množství práce na Video4Linux skočil do kódu EDAC (memory error detection and correction, detekce a oprava chyb paměti) Nehalemu a přidává nové jádro správy infračervených řadičů. Eric Paris odvedl spoustu práce na pročištění bezpečnostních záležitostí; také má naplánován subsystém fanotify. Eliot Blennerhassett má naopak jediný patch: Ovladač pro zvuková zařízení AudioScience.

Bude zajímavé se podívat na to, jak bude tento seznam změn vypadat na konci začleňovacího okna 2.6.35. A ještě zajímavější bude možná seznam nejvíce neautorských podpisů:

Nejvíce neautorských podpisů (linux-next)
Mauro Carvalho Chehab	651	13,8 %
John W. Linville	507	10,8 %
David Miller	462	9,8 %
Greg Kroah-Hartman	411	8,7 %
Ingo Molnar	170	3,6 %
Avi Kivity	156	3,3 %
James Bottomley	155	3,3 %
Reinette Chatre	98	2,1 %
David Woodhouse	93	2,0 %
Marcelo Tosatti	72	1,5 %

Správci subsystémů jsou ti, kdo jsou pověřeni dostáváním věcí do linux-next, takže pokud všichni dělají svoji práci, seznam by se během začleňovacího okna neměl moc měnit.

Pokud tato čísla vydrží, bude 2.6.35 vypadat jako další tišší vývojový cyklus bez obrovského množství vzrušujících nových záležitostí. Věci se ale většinou během začleňovacího okna mění a odněkud vždy vyskakují nějaká překvapení. Takže i se zdrojem, jakým je linux-next, je těžké předpovědět, jaký další vývojový cyklus opravdu bude.

Diskuse k tomuto článku

[Heron]

Ted má, jak tak koukám, Ubuntu taky hodně rád.

[trekker.dk]

Teď nedávno jsem se konečně dostal k tomu kouknout na jeho přednášku z Linux Plumbers Conference, kde mimo jiné srovnával příspěvky jednotlivých distribucí do Linuxu a věcí okolo (gcc, binutils, X, apod.) Moc příspěvků od Ubuntu nebylo.

[kolemjdouci]

Jestli myslíme stejnou přednášku (http://www.youtube.com/watch?v=LsjMbWXIcoA), tak tu spáchal G.K., ne Ted. I když jejich názory na ubuntu se asi moc lišit nebudou :)

[trekker.dk]

Pravda...

[frEon]

ale ma pravdu...

[vencas]

Při vší úctě, Ubuntu je hlavně desktopová distribuce a asi se jim moc nevyplatí mít lidi na vyvíjení speciálitek, které potřebuje na virtualizaci RedHat a Google pro své farmy nebo android. Říkat, že RedHat taky dělá distribuci Linuxu a přispívá víc než Canonical srovnává dosti vzdálené věci jen proto, že se jim oběma řekne "distribuce".

[trekker.dk]

a) při vší úctě, odpojování filesystému není žádná specialitka

b) Ubuntu využívá celé jádro, ne jenom specialitky, bylo by tudíž vhodné, aby do něj přispívali a nešušnili si změny jenom pro sebe

[Michal2]

Jupiii, mnozstvi zmen se snizuje, treba se nekdo zacne zabyvat i stabilizaci? Mam ten pocit, ze prumerny uptime serveru nam s kazdou novou verzi jadra pekne klesa zhruba od 2.6.24. Pet plne vytizenych serveru z sesti s timto jadrem vydrzelo pres 400 dnu. To se s novymi jadry udelat IMO neda. Statisticky vyznamny vzorek, pravda, nemam... Pozoruje jeste nekdo stejny trend nebo se mi to zda?

[trekker.dk]

Pet plne vytizenych serveru z sesti s timto jadrem vydrzelo pres 400 dnu.

Tak ti nevim, jestli je dobré se chlubit tím, že provozuješ servery se známými bezpečnostními chybami v jádře...

[nikdo]

Nikde není psáno, že by to byly servery v internetu... A "doma" (rozuměj intranet) nechť si každý provozuje co je mu libo...

[zulu]

Nejen, že jsou servery, kde některé chyby nevadí, on je klidně mohl mít opravené.

[David Jaša]

Je ta účast Broadcommů poznat třeba tak, že jsou už jejich síťovky míň fuj?

[Jardík]

jardiksu rm -rf /lib/modules/*

[geebranz]

Stat looks fine

smallbusinessloansmodesto.com