Jaderné noviny – 14. 10. 2010: Multitouch a patentové nesnáze

29. 10. 2010 | Jirka Bourek | Jaderné noviny | 4555×

Aktuální verze jádra: 2.6.36-rc7. Citáty týdne: Linus Torvalds, Valerie Aurora a další. Vydán Linsched 2.6.35. Žádné fanotify v 2.6.36. ARM: nepořádek v několikanásobně mapované paměti. Přichází vícedotykový synaptics – možná. Statistiky vývojového cyklu 2.6.36.

Obsah

• Aktuální verze jádra: 2.6.36-rc7
• Citáty týdne: Linus Torvalds, Valerie Aurora a další
• Vydán Linsched 2.6.35
• Žádné fanotify v 2.6.36
• ARM: nepořádek v několikanásobně mapované paměti
• Přichází vícedotykový synaptics – možná
• Statistiky vývojového cyklu 2.6.36

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

Současné vývojové jádro je 2.6.36-rc7 vydané 6. října. Mělo by to být poslední -rc, nevidím žádný důvod zdržovat vydání. Stále bylo více změn v drivers/gpu/drm, než bych doufal, ale všechny vypadají neškodně a dobře. Skvělá poslední slova. Zkrácený changelog je v oznámení; na kernel.org najdete kompletní changelog.

V době psaní tohoto článku není konečná verze 2.6.36 ještě vydána, ale očekávat to lze každým okamžikem.

Stabilní aktualizace: během uplynulého týdne žádné nevyšly.

Citáty týdne: Linus Torvalds, Valerie Aurora a další

V dnešní situaci si implementace mnoha 'vysokoúrovňových' programovacích jazyků při práci konkurují s jádrem. Sběr odpadu (garbage collection) bez stránkování demonstrovalo 218násobné zlepšení latencí a 41 násobné zlepšení propustnosti, když se GC a stránkovací systém jádra spojily (což vyžaduje patch Linuxu). Inteligentní, racionální lidé se často zaleknou představy vysokoúrovňového jazyka jako OS, protože GC – podle jejich zkušeností – zavádí příliš mnoho problémů s výkonností – a nevšímají si toho, že GC nikdy neměl férovou a přenositelnou příležitost využít vlastnosti hardwaru, protože si je uzurpuje jádro OS!

-- „dmbarbour“

Ať se snažím, jak chci, tohle vždy čtu jako „DAMAGED“. Nemůžu si pomoct, ale tohle podprahově ovlivňuje názory čtenáře na patch.

Já samozřejmě exceluji, když dojde na pojmenovávání, vizte „chunkfs“ a „relatime“. Nicméně pár návrhů pro pojmenování různých konceptů v tomto patchi:

D_MIGHT_MOUNT
D_CHILL_OUT
D_ITS_COMPLICATED

-- Valerie Aurora

Upřímně, pokud někdo má něco v „next“ (a je to opravdu myšleno do příštího začleňovacího okna, ne do současného) a je to označené jako stabilní, považuju to za neobvykle špatný vkus. To obratem znamená, že značka „stabilní“ je také velmi pochybná. Rozhodně to nemůže být dost důležité pro stabilní jádro, jestliže to není agresivně tlačeno do současného -rc.

-- Linus Torvalds

Takže změna jaderných rozhraní, která jsou exportována do uživatelského prostoru, je vždycky katastrofa. Každý, kdo navrhuje takovéto katastrofy, by se neměl účastnit vývoje jádra, protože ukazuje svoji neschopnost pochopit problémy a trápení.

-- Linus Torvalds

Ahoj, NSA. Jsem první člověk na světě, který byl zabanován na linux-kernel. Zakázán jsem byl za dávení off-topic věcí jako je fungující démon pro interpreter zásobníkového stroje, „Proč C překladač pro Plan 9 nemá asm("")“ a pro balíčky vhodnou internacionalizaci jmen souborů ve stromě. Níže je přiložena triviální shellová funkce, která se zbavuje make.

-- Rick Hohensee je zpátky (díky Valerii Auroře)

Milý Martine,

jsi ze stejného HTC, které je zmíněno zde?

[htc-willfully-violates-gpl-t-mobiles-new-g2-android-phone]

Pokud ano, zeptej se, prosím, znovu za 90-120 dní. Do té doby si musíš poradit sám.

-- Matt Mackall

Vydán Linsched 2.6.35

Linsched je simulátor linuxového plánovacího subsystému v uživatelském prostoru; má pomocí vývojářům, kteří pracují na zlepšení (nebo pochopení) plánovače. Byla vydána nová verze založená na 2.6.35. Vzhledem k tomu, že Linsched umožňuje modelovat libovolné topologie hardware, umožňuje testování změn plánovače na hardwaru, který pro vývojáře není snadno dostupný. Například většina vývojářů nemá přístup ke stroji se čtyřmi čtyřjádry, ale mohou použít LinSched k tomu, aby zjistili, jak jejich změny ovlivní plánovač na takových strojích. Google (původce této verze, ale ne původní vývojář) používá Linsched k ověření výsledků své práce na plánovači.

Žádné fanotify v 2.6.36

napsal Jonathan Corbet, 12. října 2010

Subsystém fanotify (původně „TALPA“) by navržen jako háček, který umožní protimalwarovým aplikacím zachytit – a potenciálně zablokovat – na soubory orientovaná systémová volání. Začleňování tohoto kódu do hlavní řady je dlouhodobý proces, který zahrnoval redefinici požadavků, přepracování nízkoúrovňového kódu notifikací ve VFS a přepracování rozhraní pro uživatelský prostor. Po vší této práci se vývojáři fanotify Ericu Parisovi podařilo kód začlenit během začleňovacího okna 2.6.36. Vývojáři začali rozhraní používat k zajímavým věcem; Lennart Poettering například zmínil, že ho používá k monitorování přístupů k souborům, aby zlepšil doby bootování systému. Zdálo se, že dlouhý příběh se chýlí ke konci.

Pak přišel Tvrtko Ursulin a upozornil na problém se systémovými voláními fanotify; následoval ještě s jedním problémem. Zdá se, že rozhodnutí o povolení se vždy neprovedla dobře a systémové volání fanotify_init() někde po cestě ztratilo parametr priority. Hlavně druhá záležitost je závažná, protože ovlivňuje ABI pro uživatelský prostor, které musí být udržováno navždy.

Eric problémy potvrdil a začal pracovat na způsobech, jakým je obejít před vydáním 2.6.36, ale Alan Cox doporučil opatrnější přístup:

Vzhledem ke dvěma „ale propána“ na poslední chvíli by bylo bezpečnější jednoduše ustoupit a před vydáním stáhnout syscall/prototyp (s tím, že zbytek zůstane). Ty se potom mohou přidat do dalšího jaderného stromu a pokud opravy priority budou fungovat dobře, mohlo by to být dost malé pro –stable.

Eric, kterému se tento nápad příliš nelíbil, ještě chvíli pokračoval v diskuzi. Nakonec ale zaslal patch, který vypíná systémová volání fanotify:

Tuto vlastnost lze přidat s kompatibilním ABI v tomto vydání (použitím některých bitů v poli příznaků, které by obsahovaly potřebné informace), ale Alan navrhl, že bychom měli prostě počkat do příštího cyklu a nejspíše přidat (nový) explicitní parametr k systémovému volání. Tento přístup se mi příliš nelíbí, protože vím, že lidé již používají současné rozhraní, ale Alan je vševědoucí a nikdo v konferenci mě nepodpořil v tom použít, co máme. Mám pocit, že zbytečně na poslední chvíli podtrháváme koberec, na kterém lidé stojí, ale jestliže si ostatní myslí, že je potřeba přidat další parametr, možná to bude nejlepší cestou kupředu.

Linus patch přijal, takže i když kód fanotify bude ve vydání 2.6.36 přítomen, nebude přístupný z uživatelského prostoru. Jestli problém bude možné vyřešit způsobem, který bude použitelný pro stabilní verzi 2.6.36.y, to se ještě uvidí.

ARM: nepořádek v několikanásobně mapované paměti

napsal Jonathan Corbet, 12. října 2010

Obecným pravidlem je, že změny v jádře, které za běhu rozbijí ovladač, se nepovažují za dobrou věc. Tiché poškození dat je také považováno za výsledek, kterému se jaderná komunita raději vyhne. Co se stane, když je nutné vybrat si mezi jedním nebo druhým? Dlouhá debata v komunitě ARM poskytuje přinejmenším jednu odpověď.

Nejprve nějaký úvod. Současné procesory normálně neadresují paměť přímo; místo toho se přístupy do ní zprostředkovávají pomocí mapování vytvořeném v jednotce pro správu paměti [memory management unit]. V závislosti na konkrétním typu procesoru mohou tato mapování být řízena pomocí segmentových registrů, záznamů v tabulce stránek nebo jinými způsoby. Mapování přeloží virtuální adresu na fyzickou adresu, ale také řídí, jak bude procesor k paměti přistupovat a jestli se bude cachovat její obsah.

Jak vysvětlil správce ARM Russel King, ARM procesory mají mnoho atributů, které ovlivňují, jak funguje mapování paměti. Je zde koncept typů paměti; například „normální paměť“ podléhá změně pořadí zápisů a čtení, zatímco „paměť zařízení“ ne. Také je zde bit, který označuje, jestli danou paměť lze sdílet mezi procesory; nesdílená paměť je rychlejší, protože není potřeba řešit koherenci cache mezi procesory. A jako mnoho CPU mohou procesory ARM specifikovat různé chování cache pro dané mapování; RAM může být mapována s tím, že se zpětný zápis cachuje, zatímco paměť zařízení cachována není.

Jádro ARM mapuje RAM jako normální paměť s cachováním zpětného zápisu; na jednoprocesorových systémech je také označena jako nesdílená. Systémové volání ioremap(), které se používá pro mapování I/O paměti pro CPU, je odlišné: tato paměť se mapuje jako paměť zařízení, necachovaná a možná sdílená. Tato lišící se mapování poskytují očekávané chování pro oba typy pamětí. Věci začnou být záludné, když někdo zavolá ioremap(), aby vytvořil nové mapování pro systémovou RAM.

Problém těchto lišících se mapování je v tom, že budou mít různé atributy. Od verze 6 architektury ARM je specifikované chování pro takovou situaci „nepředvídatelné“. Uživatelé, což je pravidlem, „nepředvídatelné“ chování nemají rádi, obzvláště když jde o jejich data. Dávalo by tedy smysl vyhnout se násobným mapováním paměti s různými atributy. Architektura ARM nicméně tradičně tento druh mapování umožňuje, výsledkem toho je, že mnoho ovladačů závisí na tom, že mohou RAM takto přemapovat.

V dubnu Russel vyhlásil, co se této záležitosti týče, poplach a zaslal patch, který způsobí, že ioremap() selže, pokud je cílem systémová RAM. Tato změna se vyhýbá potenciální záležitosti s poškozením dat, ale je to za cenu rozbití všech ovladačů, které takto používají ioremap(). V té době na to byly stížnosti, takže patch během vývojového cyklu 2.6.35 čekal, ale Rusel ho začlenil do 2.6.36. Tam byl do doby, než s blížícím se vydáním Felipe Contreras zaslal patch, který tuto změnu ruší, s tím, že:

Mnoho ovladačů nefunguje a na dohled není žádná alternativa. Takto velká změna by měla prozatím zůstat jenom jako varování a teprve později by to mělo opravdu selhat.

Russelovi se to nelíbilo. V jeho pohledu je remapování paměti tímto způsobem nebezpečnou technikou, která dříve či později povede k poškození dat. Přestože byli před šesti měsíci varováni, vývojáři ovladačů problém neopravili – rozbitých ovladačů je tolik, kolik jich bylo předtím. Podle Russelova mínění tedy není důvod dál čekat; nebezpečné chování je potřeba zastavit, než bude někdo popálen.

Na druhou stranu vývojáři ovladačů upozorňují na to, že „se zdá, že všechno funguje“ tak, jak to je, a že není potřeba něco urgentně řešit. Krom toho Russelův patch jim připadá jako změna API a běžným pravidlem vývoje jádra je, že kdo mění interní API, musí vyřešit výsledné problémy. Oprava ovladačů není jednoduchý úkol a Russel tvrdí, že byly rozbité vždycky, takže není ochoten (možná ani schopen) je všechny zase zprovoznit.

Situace vypadala nerozhodně, přičemž odstranění patche vypadalo jako jediný způsob, jakým postoupit kupředu. Nicméně ve skutečnosti to vypadá, že existuje cesta ven. Prvním krokem je umožnit tato mapování ještě v jednom cyklu, ale vypsat přitom varování viditelné pro uživatele, když k nim dojde. Jak to řekl Andrew Morton:

Máme plán: od 2.6.36 jádro vypíše WARN_ON, když ovladač něco takového udělá. Chybný kód bude odhalen, vývojáři dostanou hlášení o chybě od vystrašených uživatelů atd. To je obvykle poměrně efektivní.

Jsou to ti „vystrašení uživatelé“, kdo v této rovnici zatím chybí; ti mohou vyvolat ten tlak, který vystrašení správci subsystému vyvolat nemohou.

Dalším kouskem řešení by bylo poskytnout vývojářům ovladačů způsob, kterým by mohli získat kus fyzicky spojité RAM, kterou by bylo možné takto přemapovat. Takovou paměť není možné simultánně mapovat jako systémovou RAM. Hezký nápad by byl jednoduše odmapovat systémovou paměť, když ji začne používat zařízení, ale implementovat to se ukazuje jako obtížné. Alternativou je odložit si při bootu nějakou paměť stranou a nikdy jádru neumožnit použít ji jiným způsobem; ovladače by si pak mohly podle potřeby alokovat z této zásoby. Russel zaslal patch, který takové odkládání paměti umožňuje.

Tato konkrétní situace tedy pravděpodobně bude mít šťastný konec, za předpokladu, že k uvedenému výše nakonec dojde a že žádný uživatel nebude popálen nepředvídatelným mapováním v jádře 2.6.36. Zdůrazňují se zde ale trvající problémy. Může být velmi obtížné přinutit vývojáře k tomu, aby věci opravili, obzvlášť když současný kód „podle všeho funguje“. Tito vývojáři se o změně dozvídají velmi pozdě – pokud o ní vůbec ví. Zdá se, že vývojáři -rc jádra netestují tak, jak bychom si přáli. Zdá se nicméně, že vývojový proces funguje a problémy, jako je tento, jsou nakonec překonány.

Přichází vícedotykový synaptics – možná

napsal Jonathan Corbet, 11. října 2010

Na myši založená rozhraní s jedním ukazatelem s námi asi ještě nějakou chvíli budou, ale mnoho zajímavé vývojové aktivity, co se uživatelských rozhraní týče, dnes probíhá u vícedotykových zařízení – u těch, která dokáží sledovat více vstupních pozic zároveň. Vícedotykové rozhraní lze nalézt na mnoha smartphonech s dotykovými obrazovkami a na některých laptopech s trackpadem. Vícedotykové obrazovky mají také mnoho zajímavého potenciálu a na jiných místech – představte si třeba několik lidí, kteří pracují na obrazovce o velikosti tabule (nebo zdi). Na nejnižší úrovni nicméně detekce více dotyků zároveň potřebuje podporu v hardwaru a u mnoha na touchpadech založených systémech tento hardware pochází od Synaptics.

Linuxový ovladač pro touchpady Synaptics v současnosti nepodporuje vícedotykový režim z obvyklého důvodu: Synaptics se neuráčil sdělit světu, jak jejich hardware používat. Je tu nicméně naděje na změnu: Chase Douglas nedávno zaslal sadu patchů pro ovladač Synaptics, která přidává podporu pro touchpady založenou na informacích získaných pomocí reverzního inženýrství. Stále je potřeba vyřešit pár zádrhelů, ale daný režim podle všeho funguje. Bohužel to nutně nemusí znamenat, že budeme mít podporu pro běh v tomto režimu již v blízké budoucnosti; skutečné potíže mohou nastat mimo říši techniky.

Když Chase zaslal své patche, Takashi Iwai – více známý díky své práci na zvukových ovladačích ALSA – odpověděl, že na podpoře vícedotykového režimu pracoval také:

Paráda! Konečně na to někdo přišel! Přišel jsem na to a vyrobil jsem sérii patchů před 4 měsíci. V té době mi právní oddělení Novellu zakázalo zaslat patche do upstreamu kvůli „možnému porušení patentů“.

V následující diskuzi se ukázalo, že Chaseův patch je ve skutečnosti Takashiho patch s nějakými zlepšeními. Takashi zjevně patch jednou zaslal předtím, než právníci z Novellu toto cvičení stopli; tato práce zůstala zahrabaná na stránce v Launchpadu, načež o ni Chase zakopl, udělal pár zlepšení a kód znovu zaslal. (Jenom pro jistotu: nezdá se, že by se Chase pokoušel přisvojit si zásluhy za kód někoho jiného; jenom nepochopil původní zdroj kódu.)

Takashi evidentně považuje nezávislé zaslání kódu jako dostatečné k tomu, aby se obešly námitky právního oddělení Novellu vůči začlenění; přestože je údajně na dovolené, reagoval s entuziazmem. Chaseovy patche byly doplněny sérií patchů pro X.org, které využívají novou podporu v jádře a přidávají na uživatelské úrovni podporu pro hezké věci jako ovládání třemi prsty a gesta „štípnutí“. Veškerý tento kód, jak se zdá, čekal na příležitost utéci do divočiny; potřeba bylo jenom to, aby někdo jiný zaslal kód na straně jádra.

Takže se zdá, že stavidla jsou otevřená a podpora pro zařízení Synaptics bude dostupná pro všechny. Jenže se tu ještě může objevit háček. Jak Chase poznamenal: Jestliže jsi původním autorem této práce a můj patch bude přijat, myslím, že od tebe budeme potřebovat Signed-off-by. Bez Takashiho podpisu by kód do hlavní řady nemusel být začleněn. Takashi naznačil, že by bylo možné použít jeho podpis z původní verze, ale zdá se, že nyní nechce kód s podpisem zaslat znovu.

A tady mohou přijít problémy: autor článku nemá žádné kontakty v právním oddělení Novellu, ani žádné tajné informace, ale nebylo by překvapením zjistit, že jejich obavy z tohoto kódu nepůjde smést tak snadno. Je tedy možné, že nový podpis od Takashiho nebude. Nebo možná distributoři dostanou strach ze stejného důvodu jako Novell a rozhodnou se, že danou vlastnost nezapnou. Kód je venku několik měsíců, ale k uživatelům se nedostal; narůstající pozornost, které se mu dostává, nemusí být dostatečná k tomu, aby se tento fakt změnil.

Nemožnost použít Takashiho kód – pokud na to opravdu dojde – nebude velký problém. Důležitá je zde informace o tom, jak funguje hardware; s ní nějaký energický hacker nepochybně změnu reimplementuje rychle. Vyřešit obavy z patentů by nicméně mohlo být složitější. Bez znalostí toho, které patenty jsou zde problematické, je těžké říci, jak velkou překážku budou tvořit. Podle některých tvrzení jsou patentována vícedotyková zařízení obecně, i když to podle všeho nezastavilo některé společnosti před tím, aby taková rozhraní přidali do svých produktů. Jestliže to nicméně zastaví distributory Linuxu, prohrají uživatelé.

To je samozřejmě povaha systému softwarových patentů. Scénář popsaný výše je nicméně prozatím vysoce spekulativní. Důležitá věc je, že kód (společně se s ním spojenými informacemi o hardwaru) je venku a dostupný všem, kdo ho chtějí do svých systémů začlenit. Doufejme, že brzy bude k dispozici šířeji. Čekání na ty hezké displeje o velikosti zdi možná bude o trochu delší.

Statistiky vývojového cyklu 2.6.36

napsal Jonathan Corbet, 13. října 2010

V době psaní tohoto článku byl vydán (při troše štěstí) poslední předpatch 2.6.36 a konečnou verzi můžeme očekávat během pár dní. Je tedy čas podívat se na to, jak probíhal tento vývojový cyklus. Je několik věcí, které 2.6.36 odlišují od jeho předchůdců.

Jádro 2.6.36 bude obsahovat přibližně 9400 sad změn od 1159 vývojářů. Pokračuje tedy trend méně aktivních vývojových cyklů; následuje tabulka s výpisem toho, co jsme viděli za poslední cca rok.

Verze	Změn
2.6.31	10,883
2.6.32	10,998
2.6.33	10,871
2.6.34	9,443
2.6.35	9,801
2.6.36	~9,400

Práce, která zvýšila počty sad změn v dřívějších vývojových cyklech (na vrcholu seznamu je přebírání kódu mimo strom do adresáře staging), stále odeznívá, stejně tak práce v jiných oblastech (jako jsou nové souborové systémy.) Výsledkem je, že jádro prochází obdobím relativně pomalých změn – tedy aspoň v porovnání s posledními léty - a stabilizace. Zde stojí za to poznamenat, že pokud se nestane nic neočekávaného, vývojový cyklus 2.6.36 bude jeden z nejkratších za poslední dobu; výsledkem je to, že počet sad změn začleněných za den je nejvyšší od 2.6.30.

Nejzajímavější je pravděpodobně tato sada čísel: v 2.6.36 vývojová komunita přidala 604 000 řádek kódu a smazala 651 000 – celkově se tedy ztrácí 47 000 řádek kódu. To je poprvé od počátku éry gitu, kdy velikost zdrojových kódů jádra klesla. Vzhledem k tomu by tentokrát mohlo být vhodné podívat se na to, kdo tak pilně odstraňoval kód z jádra:

Nejvíce odstraněných řádek – 2.6.36
Sam Ravnborg	205813	31.6%
Benjamin Herrenschmidt	133666	20.5%
Amerigo Wang	19145	2.9%
Tony Luck	8418	1.3%
Greg Kroah-Hartman	7094	1.1%
Kiran Divekar	4487	0.7%
Palash Bandyopadhyay	4457	0.7%
Vincent Sanders	3467	0.5%
Dave Jones	2600	0.4%
Christoph Hellwig	2163	0.3%

Sam Ravnborg a Ben Herrenschmidt se oba dostali na vrchol seznamu tím, že odstranili spoustu souborů defconfig jako součást obecného pročištění, které inspirovala Linusova nevrlost v červnu; Sam také dokončil nějakou práci na sjednocení SPARC. Amerigo Wang odstranil mnoho starých a nepoužívaných ovladačů. Třemi z nich se zbavil téměř 360 000 řádků kódu – chvályhodná práce.

Pohled na změny v kódu obecně pro vývojový cyklus 2.6.36 ukazuje následující:

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

Podle sad změn Vasilij Kulikov 160 1.7% Eric Paris 124 1.3% Dan Carpenter 122 1.3% Chris Wilson 117 1.3% Eric Dumazet 108 1.2% Uwe Kleine-König 103 1.1% Axel Lin 98 1.0% Johannes Berg 97 1.0% Al Viro 96 1.0% Julia Lawall 89 1.0% Tejun Heo 88 0.9% Joe Perches 83 0.9% Christoph Hellwig 73 0.8% Alex Deucher 71 0.8% Ben Skeggs 69 0.7% John W. Linville 68 0.7% Stefan Richter 64 0.7% Stephen M. Cameron 62 0.7% Felix Fietkau 60 0.6% Randy Dunlap 59 0.6%

Podle změněných řádek Sam Ravnborg 208270 19.4% Benjamin Herrenschmidt 134811 12.5% Chris Metcalf 53204 4.9% Omar Ramirez Luna 51087 4.8% Amerigo Wang 19191 1.8% Jarod Wilson 16020 1.5% Felix Fietkau 11898 1.1% Alan Olsen 11650 1.1% Mike Thomas 11087 1.0% Lars-Peter Clausen 10795 1.0% Tony Luck 9351 0.9% Tetsuo Handa 7955 0.7% Casey Leedom 7888 0.7% John Johansen 7591 0.7% Greg Kroah-Hartman 7195 0.7% Charles Clément 6864 0.6% Dmitry Kravkov 6754 0.6% Kiran Divekar 6753 0.6% Ben Collins 6540 0.6% Christoph Hellwig 6045 0.6%

Co se sad změn týče, Vasilij Kulikov vede díky dlouhému seznamu většinou malých oprav v kódu ovladačů zařízení. Hlavní část práce Erica Parise je přidání subsystému fanotify – práce, která podle informací z doby psaní tohoto článku nebude v 2.6.36 zapnuta kvůli záležitostem týkajícím se ABI pro uživatelský prostor. Dan Carpenter je dalším mistrem malých oprav, obvykle jde o problémy identifikované nástroji pro statickou analýzu. Chris Wilson udělal mnoho změn v ovladači Intel i915 – a pak možná jeeště více změn, které opravovaly problémy, které následovaly. Změny od Erica Dumazeta byly opravy a zlepšení subsystému síťování.

Tři z prvních pěti v tabulce podle změněných řádek byli již zmíněni výše. Další dva jsou Chris Metcalf, který přidat novou architekturu "Tile", a Omar Ramirez Luna, který do stromu staging přidal ovladač TI dspbridge.

Jenom jeden z pěti vývojářů (Dan Carpenter) byl také mezi prvními pěti v 2.6.35; tentokrát se objevila spousta nových tváří.

Do jádra 2.6.36 přispělo 184 zaměstnavatelů (které jsme byli schopni identifikovat). Největší firemní přispěvatelé jsou:

Nejaktivnější zaměstnavatelé 2.6.36

Podle sad změn (žádný) 1524 16.3% Red Hat 1129 12.1% (neznámý) 865 9.2% Intel 691 7.4% Novell 404 4.3% IBM 374 4.0% Nokia 212 2.3% Texas Instruments 189 2.0% (školství) 178 1.9% Samsung 178 1.9% Fujitsu 160 1.7% NTT 151 1.6% Pengutronix 145 1.6% AMD 131 1.4% Google 125 1.3% (konzultant) 109 1.2% Societe Francaise de Radiotelephone 108 1.2% QLogic 107 1.1% Atheros Communications 99 1.1% MiTAC 98 1.0%

Podle změněných řádek (žádný) 299115 27.8% IBM 151386 14.1% Red Hat 76455 7.1% (neznámý) 71662 6.7% Tilera 64825 6.0% Texas Instruments 63521 5.9% Intel 55167 5.1% Novell 25798 2.4% Samsung 14619 1.4% NTT 12187 1.1% Marvell 10769 1.0% Chelsio 10560 1.0% (školství) 10345 1.0% QLogic 9873 0.9% Google 9503 0.9% Broadcom 8391 0.8% ST Ericsson 8390 0.8% Canonical 8354 0.8% Nokia 8060 0.7% Atheros Communications 7762 0.7%

Z větší části seznam vypadá jako v ostatních vývojových cyklech, ale je zde několik nových jmen. Jedním je Tilera, což firma stojící za architekturou Tile, jejíž podpora byla do 2.6.36 začleněna. Další jméno, které se objevuje prvně, je Canonical, kterému se konečně podařilo začlenit bezpečnostní modul AppArmor. Nemělo by se ale zapomenout ani na dalších 164 firem, které se nedostaly na seznam největších přispěvatelů; komerční ekosystém okolo Linuxu je stále silný a rozmanitý.

Nakonec se autor článku rozhodl, že zopakuje starý experiment a podívá se na životnost kódu v jádře. Každý řádek v jádře byl mapován na vydání jádra, ve kterém se naposledy změnil a pak byly vykresleny součty pro každou verzi. Výsledný obrázek vypadá takto:

S celkovými 1.6 % reprezentuje 2.6.36 jenom relativně malou část z celkové kódové základny - nejmenší za dlouhou dobu. Téměř 29 % jaderného kódu se stále datuje zpět do éry počátku gitu, jedná se o pokles z únorových 31 %. I když je velká část jaderného kódu nová – 31 % kódu pochází z 2.6.30 nebo novějšího – velká část je tu s námi již dlouho.

Shrnuto do jednoho odstavce nebyl vývojový cyklus 2.6.36 nijak hektický, relativně málo velkých nových vlastností a poměrně hodně pročišťování. To je minimálně zčásti důvod, proč se tato verze stabilizovala rychleji než obvykle a s menším počtem regresí (10. října jich bylo hlášeno 56, pro porovnání – v 2.6.35-rc6 jich bylo 100.) Jestli 2.6.36 reprezentuje novou podobu o něco pomalejšího vývoje jádra, se ještě uvidí. V době psaní tohoto článku linux-next obsahuje 5850 sad změn, z nichž většina má pravděpodobně mířit do 2.6.37. Mnoho změn se navíc před otevřením začleňovacího okna neobjevuje, takže pravděpodobně uvidíme, že do 2.6.37 bude začleněno ještě více změn. I tak to nicméně nevypadá, že by se v linux-next tísnila vlna, která jenom čeká na to vřítit se do hlavní řady; 2.6.37 v počtu změn možná překoná 2.6.36, možná ne, ale rozhodně to nevypadá, že bychom lámali rekordy.

       

Komentáře

[Karry]

Uááá. Když někde čtu o patentech, otevírá se mi kudla v kapse. Na starém Aceru jsem měl Synaptics kde multitouch chodil bez problémů - na Linuxu. Od té doby Synaptics změnil názor na uvolňování dokumentace, nebo to tenkrát byla náhoda že ta zařízení chodila tak jak měla?

[Peter Fodrek]

k tomu synapticu z diskusie pod tym clankom na Linux weekly new, zda sa ze menam ako dat link na predplatitelom lwn dotovany link pre priatelov, takze to bude uz volny clanok

http://lwn.net/Articles/409298/

Well, that's not really the gist of what Synaptics said - They were *very* taken with the idea to make the binary driver (SGS-L - Synaptics Gesture Suite for Linux) available for everyone to download

The frontal reason of Synaptics is that they provide their own binary-only driver for OEM, thus it must suffice. So, the biggest problem is rather that they don't understand what the problem for Linux development is.

To je uplne nelogicky postup synnapticsu Maju driver a nedavaju ho zakaznikom, ale len OEM partnerom a len pre notebooky s preinstalovanym Linuxom. http://www.osnews.com/story/23175/Synaptics_Releases_Gesture_Suite_for_Linux_OEMs

ako koncovy zakaznik sa k nemu nedostanes

a ten software dokonca maju opisany na webe, http://www.synaptics.com/solutions/technology/gestures/touchpad-linux http://www.synaptics.com/about/press/press-releases/synaptics-gesture-suite%E2%84%A2-now-available-popular-linux-operating-systems

Ale stiahnut ide len Windows verzia

Toto je vrcholne zle na ich pristupe, maju ovladac, ktory nedaju k dispozici, a v staoch, kde sa notebook nedodava s Linuxom si nahraty. Napr. slovesnky Dell nedodava model s Ubuntu, aj ked ho dodava v susednom Rakusku hotak dodava.

Ten isty notebook je na slovesnku k dispozicii len s FreeDos-om.

a Synaptics mi ani len neodpoveda na poziadavku ako ziskat SGS-L To je na tom blbe, a este aj brani vyrobit OSS ovladac iym

[bohyn]

Kdyz to dodava jen s predinstalovanym OS, a nevis o tom, tak to pak staci premaznout novejsi verzi nebo jinym distrem a ses zase v haji. :(

[Kaa]

heh.. jsem mirne zmaten ze AppArmor protlacil do kernelu Canonical, asi si potrebuji napravit reputaci. Mel jsem pocit ze to je (i kdyz ne uplne puvodni) ditko Novellu (oSuse to ma uz dlouho a doted). Ale jak tak ctu, pustili to z paratu v roce 2007.

[voda]

Třemi z nich se zbavil téměř 360 000 řádků kódu – chvályhodná práce.

Nemělo by tady spíš být: Tři zmínění se zbavili téměř…

[trekker.dk]

Já měl za to, že je tím myšleno, že tři ovladače zabíraly 360000 řádků kódu. Na druhou stranu 120k řádků na ovladač je blbost, takže máš asi pravdu.

[voda]

Hlavně když si sečteš ty první tří čísla, tak se dostaneš na cca těch 360k řádek.

[pc2005]

V následující diskuzi se ukázalo, že Chaseův patch je ve skutečnosti Takashiho patch s nějakými zlepšeními. Takashi zjevně patch jednou zaslal předtím, než právníci z Novellu toto cvičení stopli; tato práce zůstala zahrabaná na stránce v Launchpadu, načež o ni Chase zakopl, udělal pár zlepšení a kód znovu zaslal. (Jenom pro jistotu: nezdá se, že by se Chase pokoušel přisvojit si zásluhy za kód někoho jiného; jenom nepochopil původní zdroj kódu.)

Člověk by skoro řekl, že se domluvili .

[Pavel Francírek]

Mimochodem, všimli ste si, že HTC ty zdrojáky zveřejnila den po reakci Matta Mackalla?

[Karry]

Funny :) Opravdu dobře zvolený postoj...