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

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

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.

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!

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

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:

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

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:

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:

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á

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é:

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

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.

Diskuse k tomuto článku

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?

unzip; strip; touch; grep; finger; mount; fsck; more; yes; umount; sleep

29.10.2010 14:02 Peter Fodrek
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 10. 2010: Multitouch a patentové nesnáze

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

29.10.2010 15:54 bohyn
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 10. 2010: Multitouch a patentové nesnáze

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. :(

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ěř…

30.10.2010 13:56 trekker.dk | skóre: 72
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 10. 2010: Multitouch a patentové nesnáze

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.

Quando omni flunkus moritati

30.10.2010 19:09 voda | skóre: 28
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 10. 2010: Multitouch a patentové nesnáze

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