Jaderné noviny – 26. 5. 2010

18. 6. 2010 | Jirka Bourek | Jaderné noviny | 2665×

Aktuální verze jádra: 2.6.34. Citáty týdne: Rusty Russel, Alan Cox. Omezení slabu. Nejistota u blokování uspání. Začleňovací okno 2.6.35, část druhá. Vylepšení Video4Linux2 v 2.6.35.

Obsah

• Aktuální verze jádra: 2.6.34
• Citáty týdne: Rusty Russel, Alan Cox
• Omezení slabu
• Nejistota u blokování uspání
• Začleňovací okno 2.6.35, část druhá
• Vylepšení Video4Linux2 v 2.6.35
  • Zařízení s přenosem z paměti do paměti
  • Události
  • Jádro pro IR zařízení
  • Závěr

Aktuální verze jádra: 2.6.34

Začleňovací okno 2.6.35 je stále otevřené, takže v době psaní tohoto článku není vydána žádná vývojová verze. V článku níže vizte shrnutí toho, co se zatím událo.

Stabilní aktualizace: Jádra 2.6.27.47, 2.6.32.14 a 2.6.33.5 byla vydána 26. května. Co se jádra 2.6.33 týče, pravděpodobně vyjde již pouze jedna aktualizace a pak podpora pro toto jádro skončí.

Citáty týdne: Rusty Russel, Alan Cox

Chtěl jsem to změřit a ukázat ti, že se pleteš, ale povedlo se mi ukázat jenom to, že máš pravdu. To je otrava.

-- Rusty Russel

Celé tohle API mi připadá špatné. Porušuje technologické pravidlo číslo 1: „Nemůžeš vyřešit společenský problém technologií“. V tomto případě máš společensko-ekonomický problém – kód, co stojí za hovno. Ten vyřešíš ekonomicky – vytvoříš pobídku k tomu, aby takový kód nebyl vytvářen, například pomocí okénka, které bude vyskakovat a říkat „Aplikace XYZ ti vybíjí baterii“, či červenou-oranžovou-zelenou stupnicí spotřeby energie v nabídce aplikací.

-- Alan Cox

Omezení slabu

napsal Jonathan Corbet, 26. května 2010

Jaderné noviny se minulý týden krátce zabývaly novým alokátorem paměti SLEB. Od té doby Christoph Lameter zaslal druhou revizi patche, ale následující diskuze naznačuje, že SLEB se do hlavní řady nedostane.

Hlavním kritikem byl od počátku Nick Piggin, autor nezačleněného alokátoru SLQB. Nick považuje SLEB za následníka SLUBu, o kterém tvrdí, že nikdy neměl být začleněn:

Nemyslím si, že se SLUB předvedl nějak dobře. Hlavní body, kterými se chtěl prodat, byla netestovatelná tvrzení, že řazení do fronty je špatné a že rozptyl [jitter] je špatný. Zcela byl ignorován fakt, že fronty bylo možné zkrátit a periodické uklízení [reaping] šlo vypnout za běhu s alokátorem ve stylu SLAB. Také výrazně závisí na alokacích vyšších řádů, což vytváří velký tlak na alokace obrovských stránek [huge pages] a na znovuzískávání stránek [page reclaim] (všimněte si velkého zpomalení, když tmpfs používal alokace vyšších řádů pomocí SLUBu a bylo málo paměti).

Nick by byl v tuto chvíli radši, kdyby nevznikal další jaderný slab alokátor (tzn. ani ne SLQB), ale místo toho by chtěl vylepšit slab samotný, který je, jak říká, poměrně blízko k optimu. A krom toho dal Linus jasně najevo, že nehodlá začleňovat další alokátory:

Nezačlením další stupidní alokátor, který tady bude léta, nic nezlepší a bude znamenat jenom to, že se objeví nějaké chyby, které vývojáři neuvidí, protože se budou spoléhat na nějakou nenápadnou interakci se sl*b alokátorem.

Nick plánuje začít pročišťovat slab alokátor, aby byl kód přístupnější než nyní. Poté lze problémy s výkonností opatrně opravit s důrazem na to, aby se jinde neobjevily výkonnostní regrese. Postupem času, jak říká, bychom se měli dostat dál s jedním alokátorem, který bude používán (a testován) všemi, než když vytrhneme kód s dlouhou historií vývoje a nahradíme ho něčím novým a nevyzkoušeným.

Nejistota u blokování uspání

napsal Jonathan Corbet, 26. května 2010

V článku z minulého týdne se zdálo, že se konverzace o mechanismu blokování uspání v Androidu ztišuje. Takové požehnání ale, jak se zdá, nikdy není trvalé; dráty prolétlo mnoho elektronů a diskuze pokračovala. Konečný výsledek je, že se do debaty opožděně vložila jména jako Alan Cox, Thomas Gleixner a Peter Zijlstra a začlenění této vlastnosti je ještě méně pravděpodobné.

Alanův nesouhlas byl pravděpodobně nejrozumnější a nejkonstruktivnější ze všech, které byly doteď zaslány. Myslí si, že problém, který řeší blokování uspání (chybně se chovající aplikace), je reálný, ale řešení je chybné. Místo toho navrhuje přidat systémové volání setpidle(), které by určovalo rozsah, v jakém může proces zabránit systému v přechodu do klidového stavu. Jestliže bude proces nedůvěryhodná aplikace, systém bude moci být nečinný (nebo se uspat), i když by daný proces mohl běžet. Důvěryhodnější procesy (ty, které by ve schématu Androidu mohly využívat blokování uspání), by měly vyšší prioritu a mohly běžet kdykoliv.

Další kousek řešení je podle Alana vytvořit tlak na autory špatně napsaných aplikací. Thomas souhlasí:

Již se nám podařilo dokázat, že společenský tlak na autory špatných aplikací funguje. Když bylo do jádra začleněno NOHZ, nemělo to vůbec žádný vliv, protože velký počet aplikací v uživatelském prostoru používal časovače dle libosti a bez přemýšlení. Také se ukázala dotazování ve smyčce [busy polling] a jiné otřesné konstrukce. A co se stalo? Arjan vytvořil powertop, který uživateli umožňuje nalézt ty největší hříšníky v systému. Výsledkem bylo, že se aplikace rychle opravily, protože žádný správce nechtěl být na vrcholu seznamu sr*ček, který vypadl z powertopu.

Mnoho vývojářů vyjádřilo obavy, že snaha omezit dopad špatně napsaných aplikací v jádře jenom sníží tlak na vývojáře, což postupem času povede k většímu počtu špatných aplikací.

Mezitím Rafael Wysocki zaslal Linusovi požadavek na přetažení a řekl:

Ve stále probíhající diskuzi byly navrženy alternativní přístupy, ale jsou to spíše obecné návrhy než specifická technická řešení, a dokud je někdo nezkusí implementovat, nedozvíme se, jestli jsou pro Android vhodná. Z tohoto důvodu si myslím, že nemůžeme realisticky očekávat, že bude Google některý z nich implementovat. Z mého pohledu máme tedy možnost buď tuto vlastnost akceptovat, nebo úplně odmítnout.

V době psaní tohoto článku Linus neřekl, co hodlá udělat. Nicméně vzhledem k tomu, že konverzace utichla, nebude překvapení, když začleňovací okno skončí a blokování uspání v hlavní řadě nebude. Začlenění vlastnosti viditelné pro uživatele, jako je blokování uspání, by po vydání 2.6.35 nešlo odvolat; dokud je tolik neshod, vypadá rozumně ještě jeden vývojový cyklus počkat.

Začleňovací okno 2.6.35, část druhá

napsal Jonathan Corbet, 26. května 2010

Od článku z minulého týdne bylo do hlavní řady začleněno mnoho kódu – nějakých 6300 neslučujících sad změn. Vypsat všechny změny je nesplnitelný úkol, i když lidé od KernelNewbies k tomu nemají daleko, ale stručné shrnutí vytvořit lze. Nejzajímavější změny viditelné pro uživatele jsou:

• Do síťového subsystému byly přidány mechanismy směrování přijímaných paketů a směrování toku přijímaných dat.

• Sada patchů pro shlukování využité paměti byla začleněna. To by mělo vést k menší fragmentaci paměti a častějším úspěchům při velkých alokacích.

• Skulina, která za určitých okolností umožňovala zaregistrovat za běhu bezpečnostní modul, byla uzavřena; bezpečnostní moduly musí být přítomny během bootu.

• Subsystém pro řízení síťového provozu nyní používá jmenné prostory.

• Síťový stack nyní podporuje protokol rozhraní CPU pro komunikaci CPU a aplikace (CAIF, Communication CPU to Application CPU Interface), který se používá pro komunikaci s modemy ST-Ericsson. Také je nyní podporována verze 3 protokolu pro tunelování druhé vrstvy (L2TP – RFC 3931, Layer Two Tunneling Protocol)

• „FunctionFS“ je mechanismus, s jehož pomocí mohou USB ovladače v uživatelském prostoru vytvořit USB zařízení se složenou funkcionalitou. Ovladač „f_uvc“ staví nad touto vlastností a vytváří zařízení pro zachytávání videa, které přijímá data z uživatelského prostoru.

• Nyní je podporován mechanismus „oblasti s omezeným přístupem“ [restricted access regions] zabudovaný do procesorů Intel „Moorestown“. RAR lze použít pro zablokování přístupu zařízení (včetně procesorů) k specifickým oblastem paměti.

• Cpuidle governor „menu“ nyní obsahuje detekci vzorců nečinnosti, které se snaží chytřeji vybírat stav spánku podle nedávného chování systému.

• Slab alokátor získal podporu pro výměnu paměti za chodu.

• V souborovém systému squashfs jsou nyní podporovány rozšířené atributy.

• Pomocí nového fnctl() příkazu F_GETPIPE_SZ se nyní lze dotázat na velikost jaderného bufferu pro data roury, změnit ji lze pomoci F_SETPIPE_SZ. V době psaní tohoto článku se hodnoty pro tyto příkazy udávají v počtu stránek, ale to se v blízké budoucnosti téměř jistě změní na byty.

Mezi změny viditelné pro vývojáře jádra patří:

• Je zde nová varianta request_irq():

  request_any_context_irq(unsigned int irq, irq_handler_t handler,
                          unsigned long flags, const char *name, 
                          void *dev_id);

  Tato funkce připojí obsluhu přerušení obvyklým způsobem. Rozdíl je v tom, že se dívá, jak bude (kódem specifickým pro architekturu) nastavena přerušovací linka samotná a podle toho se rozhodne, jestli vytvoří tradiční tvrdou obsluhu přerušení [hard handler], nebo obsluhu přerušení ve vlákně [threaded handler]. Návratová hodnota je při úspěchu buď IRQC_IS_HARDIRQ, nebo IRQC_IS_NESTED.

• Také souvisí s request_irq(): Příznak IRQF_DISABLED nyní nic nedělá; v 2.6.36 bude úplně odstraněn. Všechny obsluhy přerušení se nyní volají se zakázaným přerušením; detaily o této změně vizte v článku.

• Byl začleněn mechanismus časovačů s volností [timer slack]. Volnost (která se uplatňuje pro klasické časovače, ne pro časovače s vysokým rozlišením) umožňuje systému odložit vypršení časovače o omezenou hodnotu, aby několik časovačů vypršelo ve stejnou dobu a tím se snížila četnost probouzení systému.

• Nová funkce ktime_to_ms() konvertuje hodnotu jaderného času [kernel time value] na milisekundy.

• Bylo odstraněno mnoho nepoužívaných háčků pro bezpečnostní moduly (task_setuid, sb_post_remount, sb_post_pivotroot, sb_umount_close, acct, inode_delete, sb_umount_busy, task_setgid, task_setgroups, sb_post_addmount, cred_commit a key_session_to_parent)

• API systému pro správu kvality služby správy napájení (pm_qos) bylo významně změněno; detaily vizte v tomto článku.

• Do sysfs byla přidána podpora pro „značkované adresáře“ [tagged directory support]. Tato vlastnost umožňuje přidat k sysfs adresářům značky specifické pro jmenný prostor; tyto značky potom určují, která verze adresáře (pokud vůbec nějaká) je v daném jmenném prostoru viditelná.

• Funkce kref_set() byla odstraněna poté, co se zjistilo, že ani jeden z jejích tří uživatelů ji nepoužívá správně.

• Metody read(), write() a mmap() ve struct bin_attribute získaly jako nový argument ukazatel na struct file.

• Nízkoúrovňový jaderný debugger „kdb“ byl sloučen s kgdb a začleněn do hlavní řady.

• Skript checkpatch si nyní bude stěžovat při přidávání jaderné konfigurační volby s méně než čtyřmi řádky textu nápovědy.

• V subsystému Video4Linux2 je nyní spousta nové infrastruktury včetně frameworku pro podporu zařízení s přenosem z paměti do paměti [memory-to-memory device] (zařízení pro zpracování videa), mechanismu pro hlášení asynchronních událostí do uživatelského prostoru a nového vnitřního subsystému pro infračervené přijímače.

U normálního začleňovacího okna by změny do hlavní řady proudily do konce měsíce. Linus ale dal jasně najevo, že nebude garantovat „normální“ začleňovací okna, takže může být uzavřeno dříve. Tak jako tak si nás nalaďte příští týden a dozvíte se o závěrečných změnách, které byly začleněny do 2.6.35.

Vylepšení Video4Linux2 v 2.6.35

napsal Jonathan Corbet, 25. května 2010

Vývojový cyklus 2.6.35 byl pro subsystém Video4Linux rušný, začleněna byla nová infrastruktura i nové ovladače. Tento článek poskytne přehled některých nových schopností V4L2.

Zařízení s přenosem z paměti do paměti

Hardware pro zpracování videa často obsahuje subsystémy, které jsou schopny různými způsoby zpracovávat proudy videa. Čipová sada VIA, se kterou autor článku nedávno pracoval, má například engine pro „video o vysoké kvalitě“ [high quality video, HQV], který lze použít pro změnu formátu videa, k rotaci snímků, konverzi barevných prostorů, odstranění prokládání atd. Není neobvyklé, když videoovladače používají takovýto engine k tomu, aby aplikacím zpřístupnily větší šíři formátů a možností. Když se používá v tomto režimu, je zpracovávající jednotka skryta před uživatelským prostorem; jeví se jako součást zařízení pro vstup nebo výstup.

Může se ale hodit i zpřístupnit zpracovávající jednotku jako samostatné zařízení; aplikace poté bude schopna akcelerovat operace s videem. Jádro takové jednotky zpřístupňuje pomocí různých rozhraní, hlavně pomocí API „dmaengine“. Jednoduché DMA procesory mohou přesouvat data a provádět nějaké transformace – například XOR s danou hodnotou. Složitější procesní jednotky mohou provádět kryptografické změny a opravdu se tak v jaderném kódu pro šifrování používají.

Pro zpracování videa se ale dmaengine nepoužívá. Autorovi článku nikdo důvody pro toto rozhodnutí nesdělil, ale jsou víceméně zjevné, počínaje tím, že videoprocesor nemusí umět DMA. Například procesor VIA HQV vyžaduje, aby relevantní data byla v paměti framebufferu. Více vypovídající je ale složitost transformací, které mohou probíhat. Videoproudy mají děsivé množství formátů a parametrů; pro popis proudu, se kterým chtějí pracovat, potřebují aplikace poměrně složité API. Takové API by určitě pro zpracovávání videa bylo možné vytvořit, ale není to potřeba, protože ve specifikaci V4L2 již existuje – je mnohem rozumnější využít toto API než vytvářet nové. A ke znovuvyužití API dojde přirozeně, když bude jednotka pro zpracování videa vypadat jako samostatné V4L2 zařízení.

Nová infrastruktura z paměti do paměti [memory-to-memory, m2m] je navržena tak, aby umožnila vytvoření V4L2 zařízení, která umožňují přesouvat videosnímky z jednoho bufferu v paměti do jiného a po cestě je transformovat. Zařízení je snímky krmeno, jako by to bylo obyčejné výstupní zařízení, pro popis formátu těchto snímků se používá odpovídající konfigurace. Strana pro video vstup je konfigurována s takovým formátem, jaký by aplikace ráda obdržela. Ovladač převezme snímky zapsané do zařízení aplikací, prožene je procesní jednotkou a nakonec je dá k dispozici ke čtení, jako z jiného zařízení pro zachytávání videa.

API m2m zde bude diskutováno pouze povrchně; více detailů najdete v <media/v412-mem2mem.h>. Ovladače začnou definicí sady zpětných volání:

struct v4l2_m2m_ops {
    void (*device_run)(void *priv);
    int (*job_ready)(void *priv);
    void (*job_abort)(void *priv);
};

Zpětné volání device_run() je voláno, když videoprocesor dostane nějakou práci; job_abort() je volán, když je potřeba procesní jednotku co nejrychleji zastavit. Volitelná funkce job_ready() by měla vrátit nenulovou hodnotu, pokud ovladač může v současnosti zahájit práci bez spaní.

Zpětná voláni jsou registrována:

struct v4l2_m2m_dev *v4l2_m2m_init(struct v4l2_m2m_ops *m2m_ops);

Když je zařízení otevřeno, ovladač by měl zavolat:

struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(void *priv, 
                    struct v4l2_m2m_dev *m2m_dev,
                    void (*vq_init)(void *priv, struct videobuf_queue *,
                                    enum v4l2_buf_type));

Hodnota priv je předána pomocí výše popsaných zpětných volání. vq_init() se volá dvakrát, jednou pro vstupní frontu a jednou pro výstupní; vq_init() by měla volat odpovídající inicializační funkci videobuf.

Je zde celá řada pomocných funkcí, které lze použít k implementaci mnoha operací V4L2: v4l2_m2m_reqbufs(), v4l2_m2m_qbuf(), v4l2_m2m_streamon(), v4l2_m2m_mmap() atd. Tyto funkce řeší nejtěžší části práce na implementaci m2m ovladače, volají zpětné volání device_run(), když je co na práci, a jsou k dispozici buffery. Ovladač zaplňuje buffery zpracovanými snímky a předává je systému videobuf, následně jsou předávány zpět aplikaci.

Většina detailů zde byla opomenuta, ale jádro toho, co má toto API dělat, bylo popsáno. V době psaní tohoto článku žádné ovladače v hlavní řadě toto API nepoužívají, ale několik jich bylo zasláno k revizím. Příklad použití lze nalézt v drivers/media/video/mem2mem_testdev.c.

Události

API V4L2 dominuje popis videoproudů a přesouvání snímků. Jsou zde ale i další zajímavé věci, ke kterým může dojít asynchronně. Proto byly přidány operace, které umožňují předávat asynchronní události do uživatelského prostoru. V této fázi se kód používá k tomu, aby si aplikace mohly vyžádat upozornění na události vertikální synchronizace a ztráty proudu videa.

Na úrovni API pro uživatelský prostor je několik přírůstků do zdánlivě nekonečného seznamu ioctl() příkazů V4L2: VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT a VIDIOC_DQEVENT. Jakmile si aplikace vyžádá jednu či více událostí, může se o nich dozvědět obvyklými způsoby včetně signálů a poll(); volání VIDIOC_DQEVENT umožňuje aplikaci zjistit, co se stalo.

V jádře API událostí začíná novým mechanismem pro správu manipulátorů souboru spojených se zařízením. Každý nový otevřený soubor musí být nastaven takto:

#include <media/v4l2-fh.h>

int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev);
void v4l2_fh_add(struct v4l2_fh *fh);

To nastaví spojení, která ovladačům V4L2 umožní propojit věci (jako jsou události) se specifickými otevřenými soubory.

Ovladač, který podporuje události, by měl začít voláním:

#include <media/v4l2-event.h>

int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n);

Toto volání se pokusí ujistit, že je dostupný úložný prostor alespoň pro n událostí pro tento manipulátor souboru. Události samotné jsou signalizovány:

struct v4l2_event {
    __u32                           type;
    union {
            struct v4l2_event_vsync vsync;
            __u8                    data[64];
    } u;
    /* … */
};

void v4l2_event_queue(struct video_device *vdev, 
const struct v4l2_event *ev);

K tomu je zde obvyklá sada pomocných funkcí (v4l2_event_dequeue(), v4l2_event_subscribe(), …), které mohou být volány ze zpětných volání ovladače V4L2.

V současnosti jsou události podporovány pouze ovladačem IVTV, takže tam lze hledat ukázku.

Jádro pro IR zařízení

V prosinci se Jaderné noviny zabývaly stavem ovladačů pro infračervené přijímače v jádře – nebo, alespoň co se subsystému LIRC týče – mimo jádro. Diskuze již dávno utichla, ale programování neustalo. Výsledek je, že v 2.6.35 má subsystém V4L2 nový framework pro IR přijímače. V tuto chvíli je podporováno mnoho řadičů. IR jádro také obsahuje rozhraní, které umožňuje předávat ovladačům (nebo uživatelskému prostoru) jednoduché časovací informace „značka“ [mark] a „mezera“ [space], které poté může dekódovat software; to by mělo umožnit zaháčkovat mnoho LIRC ovladačů v uživatelském prostoru do systému.

Dokumentace tohoto nového IR jádra víceméně chybí; základní informace o jaderném API lze nalézt v include/media/ir-core.h a ir-common.h.

Závěr

Pro jeden z nejaktivnějších subsystémů v jádře to bylo rušné začleňovací okno. Během několika posledních let subsystém V4L2 vybudoval ohromující infrastrukturu a dosáhl bodu, kdy podporuje téměř všechen dostupný hardware. Samozřejmě je stále ještě dost věcí na práci; e-mailová konference se zabývá podporou vícevrstvých video bufferů [multi-plane video buffer], novým frameworkem pro ovládání a dalšími. Budoucí začleňovací okna tedy pravděpodobně v této části stromu budou rušná i nadále.

       

Komentáře

[Rovano]

Krása.

[thingie]

Ty semaforové placky na hodnocení nenažranosti aplikace by fakt stálo za to mít.

[geebranz]

Good impression

fencing companies in yakima