Jaderné noviny – 2. 12. 2009

29. 12. 2009 | Jirka Bourek | Jaderné noviny | 5726×

Aktuální verze jádra: 2.6.32-rc8. Citáty týdne: Dave Airlie, Jon Smirl, Matt Mackall. Vkládání chyb a vkládání neočekávaných požadavků. Další pokus protlačit utrace do hlavní řady. Odstraňování rwzámků a IRQF_DISABLED. Jaderná podpora pro infračervené přijímače.

Obsah

• Aktuální verze jádra: 2.6.32-rc8
• Citáty týdne: Dave Airlie, Jon Smirl, Matt Mackall
• Vkládání chyb a vkládání neočekávaných požadavků
• Další pokus protlačit utrace do hlavní řady
• Odstraňování rwzámků a IRQF_DISABLED
  • IRQF_DISABLED
• Jaderná podpora pro infračervené přijímače

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

Současné vývojové jádro je stále 2.6.32-rc8. V době psaní tohoto článku bylo od vydání 2.6.32-rc8 začleněno těsně přes 200 změn včetně několika významných vylepšení subsystémů FS-Cache a mechanismu pomalé práce. Linus světu ještě nesdělil, jestli si myslí, že je toho dost na to, aby to ospravedlnilo vydání -rc9, nebo ne; zůstaňte na příjmu.

Citáty týdne: Dave Airlie, Jon Smirl, Matt Mackall

Již přibližně 8 let jsou GPU každých 6 měsíců složitější a složitější. Současná série radeonhd 4000 jenom málo připomíná radeon r100, který byl k dispozici tenkrát. Novější GPU vyžadují napsat kompletní překladač pro instrukční sadu, která je na některých místech složitější než u x86. Také mají čím dál tím více různých kombinací nastavování režimu, které je všechny zapotřebí podporovat.

Hádal bych, že množství kódu, který tvoří kompletní ovladač moderního GPU, se oproti tomu, co bylo zapotřebí dřív, pravděpodobně zvýšilo 40-50×, zatímco počet vývojářů v open source komunitě se od roku 2001 přibližně zdvojnásobil. Novější návrhy GPU nás navíc donutily znovu navrhnout architekturu GPU v Linuxu, což se muselo udělat paralelně se vším ostatním, opět s podobným počtem vývojářů. Ano, stojí to za prd, ale mělo by to poukázat na to, proč není důvod, aby 3D muselo opravdu fungovat na všech kartách.

-- Dave Airlie

Nejlepší způsob, jak zajistit, aby všechno „prostě fungovalo“, je zlikvidovat to.

-- Jon Smirl

Souhlasím s tím, že mít jenom jeden z SLAB/SLUB/SLQB by bylo hezké, ale dá spoustu práce v podobě psaní kódu a benchmarkování, abychom si mohli být jisti, že je jeden jasný výkonnostní vítěz. Vzhledem k mnoha existujícím měřítkům výkonnosti (pro začátek škálovatelnost/propustnost/latence) nevěřím, že existuje dobrý důvod pro to věřit, že MŮŽE existovat jasný vítěz. SLUB možná bude vždycky mít lepší latence a SLQB může vždy mít lepší propustnost. Pokud budete z NYSE, pravděpodobně budete mít jiné priority, než když budete z Googlu nebo z CERNu nebo ze Sony, přičemž ti všichni představují miliony dolarů. Neustálé opakování „ale měli bychom mít jenom jeden alokátor“ to nezmění.

-- Matt Mackall

Vkládání chyb a vkládání neočekávaných požadavků

Dobří vývojáři pečlivě píší svůj kód tak, aby řešil chybové stavy, ke kterým může dojít. Tento kód nicméně často trpí jedním problémem: Pokrytí testováním je obtížné – k mnoha očekávaným chybám nikdy nedojde, takže kód řešící chyby se nikdy neprocvičí. A když se věci skutečně pokazí, zotavení nefunguje tak, jak se očekávalo. Linux již několik let má framework pro vkládání chyb, který pomáhá ladit některé typy řešení chybových stavů. Tím, že vynutí selhání některých operací (konkrétně alokací paměti), může vývojářům pomoci ujistit se, že jsou chyby opravdu ošetřeny tak, jak se očekává.

Sripathi Kodi nedávno zaslal patch, který do frameworku pro vkládání chyb vkládá některé typy selhání futexů. Ingo Molnár reagoval potenciálně překvapivým požadavkem:

Místo tohoto neakceptovatelně ošklivého a jednoúčelového rozhraní v debugfs prosím rozšiř události výkonnosti tak, aby umožňovaly vkládat události. Další místa v jádře (která řeší neobvyklé stavy) potřebují/chtějí tuto vlastnost také.

Toto „neakceptovatelně ošklivé“ rozhraní existuje jako součást frameworku pro vkládání chyb od roku 2006, takže je trochu překvapující teď slyšet, že se nesmí používat. Ingo je nicméně ohledně tohoto bodu neoblomný a zdá se, že si to nenechá rozmluvit.

Rozšíření událostí výkonnosti může být z dlouhodobého hlediska správným řešením, ale tato situace zvýrazňuje past na vývojáře, která rozhodně ztěžuje účast na vývojovém procesu. Jonathan Corbet, autor tohoto článku, na svých cestách slyšel mnoho stížností od vývojářů, kteří se rozhodli něčeho dosáhnout, jenom aby jim bylo řečeno, že musí podstoupit mnohem rozsáhlejší pročišťování, aby byl jejich kód začleněn. Toto téma zaznělo i na Jaderném summitu 2009; tam se zdálo, že konsenzem je, že tento druh požadavků může velmi snadno dosáhnout nerozumných rozměrů.

V tomto případě Sripathi nebyl žádán, aby opravil zbytek kódu frameworku pro vkládání chyb, ale vkládání nové funkcionality do subsystému událostí výkonnosti i tak s největší pravděpodobností překročí rozsah původního projektu. Sripathi na tento požadavek nereagoval, takže není jasné, jestli bude mechanismus pro vkládání selhání futexů přepracován, aby splnil nové požadavky, nebo jestli tento kód prostě zmizí.

Další pokus protlačit utrace do hlavní řady

Když jsme se v březnu naposledy dívali na utrace, bylo navrženo jeho začlenění do 2.6.30. V té době se objevily různé námitky, ale největší z nich byl chybějící „skutečný“ uživatel utrace v jádře. Padl návrh, že poskytnout skutečného uživatele společně s utrace samotným by zajistilo hladší cestu do hlavní řady. Utrace se nyní vrací v podobě sady patchů od Olega Nesterova (založených na práci Rolanda McGratha) společně s přepisem systémového volání ptrace() tak, aby používalo rozhraní utrace. S blížícím se otevřením začleňovacího okna 2.6.33 je naděje, že se utrace konečně dostane do hlavní řady.

Utrace poskytuje prostředky pro řízení vláken v uživatelském prostoru, což lze využít k ladění, sledování a k dalším úlohám, jako je Linux v uživatelském režimu [user-mode-linux]. SystemTap je jedním z největších současných uživatelů utrace, takže jádra pro Red Hat a Fedoru obsahují podporu pro utrace již léta. Utrace vychází z faktu, že ptrace() bylo příliš omezené – a zaneřáděné – v mnoha situacích, kdy ho lidé chtěli použít. Konkrétně omezení na jediný aktivní sledující proces pro dané vlákno, což ptrace() vyžaduje, bylo pro některé způsoby sledování příliš omezující. Utrace umožňuje několika sledovacím „enginům“ připojit se k vláknu, vyjmenovat události, o které mají zájem, a následně přijímat zpětná volání [callback], když k dané události dojde.

Rozhraní, které utrace poskytuje, se nijak významně nezměnilo od doby, kdy jsme se na něj poprvé dívali v březnu 2007. Enginy, které jsou typicky implementovány jako nahrávatelné jaderné moduly, se připojí k danému vláknu pomocí utrace_attach_task() nebo utrace_attach_pid() v závislosti na tom, jestli mají k dispozici struct task_struct nebo struct pid. V obou případech je vrácen ukazatel na struct utrace_engine, který engine identifikuje v dalších voláních.

struct utrace_engine vypadá takto:

struct utrace_engine {
    const struct utrace_engine_ops *ops;
    void *data;
    unsigned long flags;
};

flags obsahují masku událostí a data se používá pro privátní data specifická pro engine. Nejzajímavější je pole ops, které nastavuje deset různých funkcí pro zpětná volání. Tyto funkce tvoří srdce funkcionality sledovacího enginu.

Ukazatele na funkce v struct utrace_engine_ops jsou popsány v linux/utrace.h. Všechny kerneldoc komentáře jsou přetaženy ze zdrojového kódu do dokumentace DocBook, která je dodávána spolu se sadou patchů. Ke zpětným voláním dochází, když sledované vlákno narazí na některou z událostí, mezi které patří doručení signálů, volání clone() nebo exec(), vstup nebo návrat z ostatních systémových volání, ukončení nebo smrt vlákna a další. V každém případě jsou zpětná volání enginů, které o danou událost mají zájem, prováděna v pořadí, v jakém byly enginy připojeny.

Engine používá volání utrace_set_events() (nebo utrace_set_events_pid()), kterým určuje, o které události má zájem:

int utrace_set_events(struct task_struct *target,
                      struct utrace_engine *engine,
                      unsigned long events);

Makro UTRACE_EVENT() se používá k zapnutí odpovídajících bitů v masce event. V tabulce engine->ops musí být nastavena zpětná volání pro všechny události, které jsou povoleny.

Jakmile dojde na zpětné volání, engine použije utrace_control() (nebo utrace_control_pid()), kterými sledovanému vláknu řekne, co má dělat:

int utrace_control(struct task_struct *target,
                   struct utrace_engine *engine,
                   enum utrace_resume_action action);

Parametr action určuje, co se má stát. Mezi akce patří věci jako krokování, krokování po blocích, obnovení běhu, odpojení se od vlákna atd.

Jediná skutečná stížnost na tuto sadu patchů, která se zatím objevila, byla od Christopha Hellwiga, který není šťastný z toho, že implementace ptrace() nenahrazuje současný kód ptrace(): Jedna věc, která se mi na tomhle opravdu nelíbí, je, že se zavádí dvě implementace ptrace tím, že s přidáním jedné není zároveň odstraněna druhá. V patchích je začlenění utrace řízeno konfigurační volbou CONFIG_UTRACE. Vzhledem k tomu, že systémové volání ptrace() není volitelné, musí současný kód zůstat.

Christoph nicméně navrhuje, aby byla podpora pro utrace přidána do dvou hlavních architektur, které ji nemají (arm a mips) a současné ptrace() bylo následně odstraněno. Zjevně věří, že je pozdě na to dostat utrace do 2.6.33, takže bude dostatek času na přidání podpory utrace do těchto – a doufejme, že i dalších menších architektur, předtím než bude začleněno. Pokud zbývající malé architektury nezvládnou svoje domácí úkoly včas, budou bez ptrace, řekl.

To se jiným programátorům jádra příliš nelíbilo. Pavel Machek řekl: Nemyslím si, že zavádění regresí, abychom donutili lidi přepisovat kód, je ten nejlepší způsob. Ingovi Molnárovi se podle všeho utrace od doby, kdy bylo naposledy navrženo, začalo líbit. Minule měl Ingo mnoho stížností, ale tentokrát je mnohem přístupnější. Nemyslí si, že přidávání podpory pro další architektury je správná cesta:

Co se týče portování na další architektury – to je pravděpodobně nejhorší možný nápad. Narůstá tím režie za údržbu a testování, protože se značně zvětšuje testovací matice, přičemž konečnému výsledku to prospívá jenom málo. Nejhorší efekt navíc spočívá v tom, že to potom bude mnohem rušivější a mnohem obtížnější (a riskantnější) začlenit.

Na rozdíl od minula, kdy se většina námitek netýkala přímo kódu, ale spíš jeho načasování a chybějícího uživatele v jádře, tentokrát proběhlo i nějaké revidování. Například Peter Zijlstra prozkoumal jak kód, tak dokumentaci. Je vidět, že utrace se postupně zbavuje překážek, které mu v minulosti stály v cestě.

Jeden z výsledků setkání zabývajících se sledováním na Collaboration Summit v dubnu bylo to, že je potřeba najít uživatele v jádře a ptrace() se zdál být dobrým kandidátem. Na těchto setkáních byly zmíněny i další nápady jako přidat do jádra „kousek“ [stub] gdb, který by umožňoval ladit programy v uživatelském prostoru. Srikar Dronamraju navrhl patch odhalující rozhraní /proc/PID/gdb, které implementuje vzdálený sériový protokol gdb.

Tento patch naráží na vážnější potíže než utrace. Protože kgdb již nyní odhaluje vzdálené sériové rozhraní pro gdb, ale pro jádro, myslí si Peter Zijlstra a Ingo Molnár, že by tyto dva měly být sloučeny. Zdá se nepravděpodobné, že by patch byl začleněn, dokud to nebude vyřešeno.

Některé části sady patchů utrace strávily nějaký čas ve stromě -mm a utrace se dodává ve všech jádrech pro Fedoru od FC6. Kousek zajišťující propojení utrace a ptrace nicméně nebyl ani v -mm ani v -next, takže pro něj možná bude těžší dostat se do hlavní řady v 2.6.33. Nicméně vzhledem k tomu, že je utrace volitelné, je rizik jenom málo. Roland McGrath je ochoten uvážit odstranění současné implementace ptrace(), ale je zjevné, že on i Oleg Nesterov – správci současného ptrace() – by raději začlenili utrace do jádra nyní:

Nechceme na nikoho, například na správce architektur, chvátat. Nechceme poškodit nikoho, kdo se o naši práci nezajímá (testujeme ptrace na regrese, ale je samozřejmé, že nový kód vždycky přinese nové chyby, takže je nutné očekávat nějaké potíže při přechodu na novou implementaci ptrace bez ohledu na to, jak moc se budeme snažit). Prostě jenom nechceme dál pracovat mimo strom.

Jestli se utrace dostane do 2.6.33, to se pravděpodobně dozvíme během několika následujících týdnů. Pokud se tak nestane, zdá se, že bude zapotřebí jenom jeden vývojový cyklus navíc.

Odstraňování rwzámků a IRQF_DISABLED

Spinlocky čtenář-zapisovatel [reader-writer spinlock] a obsluhy přerušení s povolenými přerušeními mají oba v linuxovém jádře dlouhou historii. Příběh obou se ale možná blíží ke konci. Tento článek se dívá ne snahu odstranit z jádra dva prastaré mechanismy pro vzájemné vyloučení.

Spinlocky čtenář-zapisovatel (rwzámky) se chovají jako běžné spinlocky, ale s několika významnými výjimkami. Zámek může naráz držet neomezený počet čtenářů; to umožňuje několika procesorům přistupovat ke sdíleným datům, pokud je žádný z nich nemění. Čtecí zámky jsou navíc přirozeně vnořovatelné; jediný procesor může jeden zámek zabrat několikrát, pokud to potřebuje. Zapisovatelé naopak vyžadují exkluzivní přístup; než lze přidělit zámek pro zapisování, musí být uvolněny všechny čtecí zámky a naráz lze držet pouze jeden zapisovací zámek.

Rwzámky jsou v Linuxu zjevně nespravedlivé v tom, že čtenáři mohou zapisovatele zdržovat na libovolně dlouhou dobu. Je povoleno získávání nových čtecích zámků i v případě, že čeká nějaký zapisovatel, takže rovnoměrný proud čtenářů může zapisovatele zablokovat neomezeně. V praxi se tento problém téměř neobjevuje, ale Nick Piggin nahlásil případ, ve kterém správná zátěž v uživatelském prostoru může způsobit nekonečný livelock systému. To je výkonnostní problém specifických uživatelů, ale na mnoha systémech je to také potenciální možnost, jak způsobit odepření služby. V reakci na to se Nick rozhodl čelit výzvě a vytvořit férovější rwzámky, které nezpůsobí výkonnostní regrese.

To není jednoduché. Zjevné řešení – blokování nových čtenářů, dokud se zapisovatel nedostane ke slovu – nebude fungovat pro nejdůležitější rwzámek (tasklist_lock), protože tento zámek mohou zabírat obsluhy přerušení. Pokud je přerušen procesor držící zámek tasklist_lock pro čtení a obsluha přerušení tento zámek potřebuje také, nutit obsluhu čekat na zámek způsobí deadlock procesoru. Použitelné řešení tedy vyžaduje umožnit získávání vnořeného zámku pro čtení, i když čekají zapisovatelé, nebo zakázat přerušení, když je držen tasklist_lock. Ani jedno z těchto řešení není úplně potěšující.

Krom toho již několik let obecně panuje názor, že by rwzámky měly být odstraněny úplně. Samotné zamykací primitivum je v tomto případě výrazně pomalejší než běžný spinlock, takže výkonnostní zisk z toho, že může číst několik čtenářů naráz, musí být dost velký na to, aby se tato cena navíc zaplatila. V mnoha případech se přitom zdá, že takový výkonnostní zisk neexistuje. Postupem času tedy jaderní vývojáři měnili rwzámky na normální spinlocky nebo je nahrazovali mechanismem čtení-kopírování zápis. I tak ale v jádře zůstává několik set rwzámků; možná by bylo lepší zaměřit se na jejich odstranění, místo aby se věnovalo spousta práce tomu, aby byly férovější.

Téměř všechny tyto rwzámky by bylo možné přes noc změnit na spinlocky a nikdo by si toho nevšiml. tasklist_lock je ale poněkud jedovatý problém; je zamykán na mnoha místech ve vnitřním jádře a není vždy jasné, co chrání. Také je zamykán na mnoha kritických rychlých cestách v jádře, takže jakoukoliv změnu je nutné provést opatrně, aby se neobjevily výkonnostní regrese. Z těchto důvodů se jaderní vývojáři většinou vyhýbali manipulaci s tasklist_lock.

I tak se zdá, že postupem času mnoho struktur chráněných tasklist_lock přešlo k jinému ochrannému mechanismu. Zámek byl také změněn ve stromě realtime preempce, i když tento kód se do hlavní řady ještě nedostal. Vzhledem k tomu se Thomas Gleixner rozhodl zkusit se tohoto zámku zbavit, řekl: Pokud mě nikdo nezbije, pustím sed ze řetězu a nechám ho proběhnout se přes zdrojáky jádra, použiju kód pro task_struct bez rcu z -rt a zjistím, co vybuchne. V době psaní tohoto článku nebyly výsledky tohoto cvičení zveřejněny, ale Thomas je v e-mailové konference stále aktivní, takže případné výbuchy zjevně nebyly smrtící.

Pokud se podaří zkonvertovat tasklist_lock na běžný spinlock, pravděpodobně rychle dojde i na konverzi ostatních rwzámků. Krátce poté mohou rwzámky zmizet úplně, čímž se významně zjednoduší sada primitiv pro vzájemné vyloučení v Linuxu.

IRQF_DISABLED

V obsluhách přerušení dochází k jinému druhu vylučování. V prvních dnech Linuxu byly obsluhy rozděleny na „rychlé“ a „pomalé“. Rychlé obsluhy mohly běžet se zakázáním ostatních přerušení, ale pomalé musely mít ostatní přerušení povolená. V opačném případě by pomalá obsluha (která může dělat spoustu práce) mohla blokovat zpracování důležitějších přerušení a tím ovlivnit výkonnost systému.

Během let toto dělení z několika důvodů postupně mizelo. Zrychlení procesorů znamená, že i obsluhy přerušení, které dělají mnoho práce, mohou být „rychlé“. Hardware je chytřejší, což minimalizuje absolutní množství práce, kterou je potřeba vykonat okamžitě po přijetí přerušení. V jádře se objevily vylepšené mechanismy (obsluhy přerušení ve vláknech, tasklety a pracovní fronty) pro odložení zpracování. A kvalita ovladačů se obecně zlepšila. Autoři ovladačů se tedy nemusí zabývat tím, jestli jejich obsluhy běží s povolenými přerušeními, nebo ne.

Tito autoři o tom ale i tak musí rozhodnout, když obsluhu přerušení nastavují. Pokud není obsluha nastavena s nastaveným příznakem IRQF_DISABLED, běží s povolenými přerušeními. Aby byla legrace ještě větší, obsluhy pro sdílená přerušení (což je na dnešních systémech pravděpodobně většina) si nikdy nemohou být jisty tím, že je obsluha přerušení zakázána; jiná obsluha na stejné přerušovací lince je může kdykoliv povolit. Mnoho obsluh tedy běží s povolenými přerušeními, i když to není potřeba.

Zdá se, že řešením je odstranit příznak IRQF_DISABLED a používat všechny obsluhy přerušení se zakázaným přerušením. Ve většině případů bude všechno fungovat dobře. Je jenom pár situací, ve kterých obsluha přerušení trvá příliš dlouho nebo kde obsluha jednoho přerušení závisí na tom, že jinému zařízení se přerušení mohou doručit kdykoliv. Tyto obsluhy lze identifikovat a vypořádat se s nimi. „Vypořádání“ v tomto případě může mít několik podob: Jednou je ovladač vybavit lépe napsanou obsluhou přerušení, která problém mít nebude. Další, s tím spojený přístup, je upravit ovladač tak, aby měl obsluhu ve vlákně, které přirozeně běží s povolenými obsluhami přerušení. A nebo nakonec by bylo možné obsluhu nastavit s novým příznakem (například IRQF_NEEDS_IRQS_ENABLED), který by zajistil, že přerušení budou povolena starým způsobem.

Není jasné, kdy k tomu všemu dojde, ale může dojít k tomu, že se v blízké budoucnosti bude od všech tvrdých obsluh přerušení očekávat, že poběží – rychle – se zakázanými obsluhami přerušení. Toho si všimne jenom pár lidí, když nebudeme počítat správce ovladačů mimo strom, kteří budou muset ze svého kódu odstranit IRQF_DISABLED. Jádro jako takové by ale mělo být rychlejší.

Jaderná podpora pro infračervené přijímače

Jedním z deklarovaných cílů stromu -staging je dovést do hlavní řady jádra široce využívané ovladače. Tato snaha je poměrně úspěšná; počet ovladačů mimo strom se za poslední rok výrazně snížil. Je zde ale jedna významná výjimka: Subsystém pro linuxový infračervený dálkový ovladač [Linux Infrared Remote Control, LIRC]. LIRC se používá k příjmu vstupních událostí od dálkových ovladačů a jejich předávání aplikacím; na Linuxu založené digitální videorekordéry jsou významnými uživateli LIRC, ale existují i jiní. V říjnu Jarod Wilson zaslal novou verzi LIRC ke zvážení. O měsíc později o ní jaderní vývojáři začali mluvit; a co jim chybělo na přesnosti bylo víc než bohatě vynahrazeno hlasitostí.

Jeden by si mohl myslet, že začlenění tohoto dlouho existujícího a využívaného projektu do hlavní řady nevyžaduje velké diskuze. Problém je v tom, že LIRC s sebou přináší nové ABI a vzhledem k tomu, že rozhraní pro uživatelský prostor musí být udržována věčně, bývají podrobována zkoumání podstatně více než jiné části kódu. LIRC nikdy nemusel během několika let svého vývoje mimo strom zmrazit své ABI, což je svoboda, která jeho vývojářům značně zjednodušovala život. LIRC v hlavní řadě by ale tuto svobodu nemělo, takže všechny nekompatibilní změny ABI je nutné provést před začleněním. A jak je obvyklé, někteří vývojáři by rádi viděli významné změny.

Na první pohled by se zdálo, že IR přijímač je jednoduché zařízení; jediné, co musí hlásit, jsou události stisku a uvolnění tlačítka podobně jako klávesnice. Zdá se ale, že s těmi nejjednoduššími zařízeními je často nejsložitější pracovat – do některých přijímačů jsou zabudovány dekodéry, což jim umožňuje předat ovladači scan kód, který je následně namapován na kód klávesy a předán aplikaci. Jiná zařízení jsou ale opravdu jednoduchá – jednoduše hlásí časování a délku impulzů přijatých od vysílače. V takovém případě musí ovladač vyfiltrovat chyby a podle protokolu informace zpracovat tak, aby následně mohl vygenerovat scan kód. A aby to bylo ještě zábavnější, protokolů se používá několik a někteří výrobci se moudře rozhodli, že život bude mnohem zajímavější, když vytvoří své vlastní verze protokolů, které se liší od protokolů všech ostatních. Zpracování podle protokolu tedy může být protivné a nepříjemné.

LIRC tento bordel řeší tak, že mu ovladače hlásí „čisté“ délky impulzů přes zvláštní zařízení; démon v uživatelském prostoru potom má za úkol tyto informace konvertovat na něco, co použitelně popisuje stisk tlačítka. V mnoha případech nízkoúrovňový ovladač běží v uživatelském prostoru a jádro vůbec nepotřebuje. Distribuci událostí také řeší LIRC démon, který může specifické události mířit k různým aplikacím, v reakci na události spouštět programy a tak dál, to vše flexibilním a skriptovatelným způsobem. LIRC funguje a někteří vývojáři by ho rádi viděli začleněný do hlavní řady víceméně tak, jak je k dispozici nyní. Jiným se však nelíbí jednoúčelové „čisté“ rozhraní, které LIRC používá. Jak to řekl Jon Smirl:

Dřív jsme měli pro klávesnici a myši specifické rozhraní pro uživatelský prostor. To způsobovalo všechny možné druhy problémů. Spousta práce byla věnována jejich sjednocení v evdev. A bude trvat léta, než bude možné zcela odstranit ta stará zmršená rozhraní.

Nejsem pro opakování těchto problémů s uživatelským rozhraním specifickým pro rozhraní v případě IR. Věřím tomu, že všechna nová vstupní zařízení by měla implementovat framework evdev.

Jinými slovy tito vývojáři chtějí, aby se dálková ovládání tvářila jako jakékoliv jiné vstupní zařízení a generovala vstupní události přes stejné rozhraní. Jon zaslal navrhovaný vstupní IR ovladač k diskuzi; jedná se o přepracovanou verzi ovladače, který byl zaslán před rokem. Kód přesouvá veškeré zpracování do jádra a poskytuje flexibilní mechanismus pro používání různých dálkových ovladačů.

Jak se tak stává, tímto způsobem funguje již mnoho přijímačů pro dálková ovládání, a to i bez Jonova patche. LIRC není jediný projekt s ovladači pro IR přijímače; mnoho jich již žije v hlavní řadě jádra v subsystému Video4Linux. TV karty se často dodávají s přiloženým dálkovým ovládáním a přijímačem, takže dává smysl napsat ovladač pro přijímač jako součást většího V4L2 ovladače. Tyto ovladače rozhraní LIRC nepoužívají, místo toho generují přímo vstupní události. Jako příklad, jak má takový druh ovladače vypadat, vizte IR ovladač Conexant CX2388x.

Diskuze pokryla různé přístupy k IR přijímačům, aniž by se dospělo k nějakému skutečnému řešení. Pokus Jona Smirla objasnit cíle pro podporu IR v jádře možná trochu pomohl, ale žádné solidní závěry z něj nevzešly. U některých bodů se dospělo k téměř-konsenzu, mezi ty patří:

• Je zapotřebí nějaké API založené na vstupním subsystému, kde mohou aplikace získat zpracované, vysokoúrovňové kódy kláves pro stisknutá tlačítka. Cílem je, aby aplikace používající dálkový ovladač „prostě fungovaly“, kdykoliv je to možné.

• Pravděpodobně je potřeba oddělené rozhraní, kde budou aplikace pro zvláštní účely moci získat čistá data o časování přímo od přijímače – alespoň u přijímačů bez zabudovaných dekodérů, které taková data poskytují. Tato rozhraní by bylo možné použít k reverznímu inženýrství sekvencí, které vysílá nový dálkový ovladač, a k vypořádání se s patologicky špatným hardwarem. Mluví se o tom, že by se čistá data také nacpala do vstupní vrstvy, ale není jasné, jestli by to něčemu pomohlo; je možné, že přijetí existujícího rozhraní LIRC pro čistá data je stejně dobrý přístup jako jakýkoliv jiný.

Ohledně rozhraní pro kódy kláves stále ještě není jasné, odkud by tyto kódy měly přicházet. Někteří vývojáři chtějí, aby všechny IR ovladače byly v jádře, zatímco jiní jsou spokojení s používáním LIRC démona (nebo něčeho podobného), který vygeneruje kódy kláves a z uživatelského prostoru je zase vloží zpět do jádra. Ovladače v jádře mají potenciál fungovat bez démona a mohou používat současný mechanismus nahrávání modulů. Jaderné ovladače budou také mít kratší dobu odezvy než démon v uživatelském prostoru, což ušetří drahocenné milisekundy zoufalým uživatelům, kteří chtějí přepnout kanál a vyhnout se tak „informacemi přeplněné“ reklamě na léky.

Na druhou stranu jsou ovladače v jádře jaderným kódem, což vždy znamená zvýšené riziko. Filtrování vstupních sekvencí a zpracování protokolů může znamenat významný objem práce, kterou by někteří raději viděli odvedenou v uživatelském prostoru. Ani se nemusí podařit podporovat problematičtější hardware v jádře. Pak jsou zde opravdu divoké nápady jako přidrátování IR přijímače k mikrofonnímu vstupu zvukové karty – což je něco, co lidé evidentně dělají. Je také nutné mít na mysli fakt, že některé IR protokoly jsou zatíženy patenty.

Další detail, na který stojí za to myslet: Mnoho IR přijímačů může informace i vysílat. Řešení založené čistě na vstupní vrstvě nemusí být schopno řešit výstup.

A nakonec je zde konečný, jednoduchý argument: LIRC ovladače jsou vyvíjeny již léta a fungují. Pokud bude LIRC začleněn přímo, jádro bude mít prospěch z této práce i z poučení, která z ní vzešla. Pokud bude LIRC odhozeno ve prospěch ovladačů plně v jádře, je určitá šance, že v některých případech bude nutné poučit se znova. Pokud pro jádro dojde na přístup, kdy budou ovladače plně v jádře, je velmi pravděpodobné, že se nakonec dostane do bodu, kdy bude obsahovat schopnější a flexibilnější systém s širší podporou zařízení, než je nyní k dispozici. Mezitím by ale bylo období – a možná dlouhé – kdy by podpora IR v jádře nebyla tak dobrá jako LIRC.

I tak je ale možné, že na to dojde. Jaderná vývojová komunita, která se vždycky pečlivě zabývá tím, co bude muset za pět či deset let udržovat, většinou nespěchá s tím něco začlenit, protože se nyní zdá, že to funguje. Takže i když začlenění LIRC do hlavní řady v podobě blízké té současné stále není ze hry, je také možné, že bude odsunuto na vedlejší kolej, zatímco se pro hlavní řadu bude vyvíjet něco výrazně odlišného.

       

Komentáře

[Martin]

s/Cíkem/Cílem/

[Hynek (Pichi) Vychodil]

Ano, to stojí za prd, ale ... je anglikanismus. V české větě nevyžadujeme, aby byl podmět před přísudkem. Ano, stojí to za prd, ale ... zní mnohem lépe.

[Nicky726]

Mám za to, že je možné obojí, akorát to má každé trochu jiný význam.

[Ash]

Možné je zcela jistě obojí, ale Pichimu prostě zní líp to druhé no... To je hezká věc, ale... je to hezká věc, ale... věc je to hezká, ale... czech rocks.

[dan.h]

To LIRC tam dávají kvůli DVD přehrávačům a podobně? Nenapadá mne zrovna moc zařízení, kde se ještě ještě používá infrared propojení. Přijde mi to dost pozdě na to, že v telefonech infraportům už odzvonilo.

(chápu, že rc8 je už dávno pryč, ale i tak se dá LIRC v jádře debatovat).

[Nicky726]

Dálková ovládání?

[geebranz]

Another attempt smallbusinessloanstylertx.com