Jaderné noviny - 8. 4. 2015: Spuštění jádra v režimu knihovny

15. 7. 2015 | Redakce | Jaderné noviny | 2718×

Stav vydání jádra. Citáty týdne. Spuštění jádra v režimu knihovny.

Stav vydání jádra

Aktuální vývojové jádro je 4.0-rc7, vydané 6. dubna, po jednom dni prázdninového zpoždění. "Pořád jde o celkem malé zpoždění a na dobré cestě pro 4.0 na příští víkend. Je malá šance, že se rozhodnu 4.0 o týden odložit, protože ten týden potom odjíždím, a chtěl bych se vyhnout otevření začleňovacího okna. Uvidíme, jak se příští víkend rozhodnu."

Stabilní aktualizace: Žádné nebyly minulý týden vydány.

Citáty týdne

Jestliže píšete interface se 4 nebo 5 argumenty funkcí, je možné, že nemůžeme být kamarádi.

-David Miller

Spuštění jádra v režimu knihovny

Kdysi dávno, bylo jedinou možností spustit Linux kernel jako hlavní operační systém na odpovídajícím hardware. Od té doby je možné využívat i jiné režimy: kernel může být spuštěn jako host jiného kernelu skrze virtualizaci nebo jako proces v uživatelském prostoru s uživatelským režimem Linux (UML). Jeden režim, který zatím nebyl podporován, umožňuje spustit kernel jako knihovnu, kterou je možné zavolat skrze aplikační program (aplikaci). To se má brzy změnit díky patch setu, který se poprvé objevil na mailing listu.

Patch set, který zveřejnil Hajime Tazaki, se jmenuje LibOS. Byl představen na nedávné konferenci Netdev 0.1. LibOS je strukturovaný jako nový port, dá se najít ve stromu pod arch/lib. Tento port se ovšem nechová jako spustitelný kernel, místo toho vytvoří sdílenou knihovnu, kterou je poté možné načíst do běžícího procesu.

Někoho by možná mohlo napadnout, jak by tento režim mohl být užitečný. Hlavním zaměřením LibOS (i když se nejedná pouze o toto použití) je snaha zpřístupnit linuxové síťové zásobníky aplikacím v uživatelském prostoru. Síťové zásobníky pro uživatelskou paměť nejsou v Linuxu věcí novou, v některých nastaveních výkonu se objevují již několik let. Díky LibOS není třeba pro psát (či portovat) nový síťový zásobník, je možné využít přímo síťový zásobník kernelu.

Bez trochy práce se ovšem volatelný zásobník nastavit nedá. LibOS vývojáři vytvořili zcela nový set stub funkcí, které mají nahradit různé funkce kernelu používané síťovým kódem. Většinu kódu tohoto patch setu opravdu tvoří tisíce řádků stub funkcí. Nahrazují např. SLAB alokátor jednodušší verzí, založenou na malloc() a z větší části eliminují vrstvu souborového systému. Zbude dost osekaného síťového zásobníku, který je možné spustit samostatně uvnitř adresního prostoru procesu.

Vlastně ho nezůstane dost, protože některé úkoly je stále třeba dělat volací aplikací. Stále chybí implementace stub pro schedule(), volající kód musí jeden poskytnout v průběhu inicializačního procesu. Běžící aplikace může chtít využít kontrolu nad řízením procesů (s největší pravděpodobností v podobě POSIX vláken).

V současné době využívají framework LibOS dva projekty. NUSE dokončuje projekt, který bude poskytovat síťový zásobník v běžícím uživatelském prostoru. V NUSE lze nastavit libovolné síťové topologie, rozhraní k jiným mechanismům uživatelského prostoru, například DPDK, pro rychlý přenos a příjem paketů atd. NS-3 simuluje rámce (framework), používané k testování síťových protokolů a implementací. Může spouštět síťově orientované aplikace (v rámci) síťového zásobníku LibOS, za pomoci LD_PRELOAD, k přesměrování volání k síťovým systémovým voláním.

S těmito nástroji se dá udělat řada zajímavých věcí. Využít by ho mohli uživatelé, používající sítě v uživatelském prostoru z důvodu výkonnosti - i když zásobník kernelu ještě v tomto nastavení nebyl pro výkon optimalizován. Někdo, kdo by mohl chtít spustit experimentální protokol (třeba MPTCP), může využít LibOS (s vhodně opatchovaným kernelem) a vyzkoušet si tuto funkci, aniž by musel sahat na síťový zásobník, který využívá zbytek systému. Využít by se dal také pro spouštění nástrojů pro odstraňování chyb (debugging tools) s použitím síťového zásobníku, běžícího v uživatelském režimu.

I když se projekt LibOS zaměřil v první řadě na síťový zásobník, nic v jeho návrhu nezabraňuje jeho využití jinde. Bylo by klidně možné izolovat vrstvu virtuálního souborového systému, stačí přijít s potřebnými stub funkcemi.

Možná by někoho mohlo napadnout, jak se LibOS liší od uživatelského režimu, který je součástí kernelu již mnoho let? Přesně takový dotaz si položil UML maintainer Richard Weinberger. Rozdílů je zřejmě několik. UML funguje jako samostatná aplikace, zatímco LibOS funguje jako knihovna, kterou volá jiná aplikace. Není tedy problém mít v rámci jedné aplikace několik instancí LibOS současně. Kromě toho možnost izolovat jeden subsystém pro použití v rámci aplikace, není součástí konstrukce UML. Po hlubším zkoumání kódu Richard souhlasil, že LibOS přináší něco nového.

Jednou z možných obav je údržba všech stub funkcí. Je jich hodně a budou muset být aktualizovány pokaždé, když dojde v kernelu ke změně jejich "skutečných" protějšků. Jen velmi málo maintainerů bude pamatovat na to, že je třeba aktualizovat jak jejich vlastní subsystémy, tak LibOS. Což ve finále znamená, že LibOS bude po většinu času nepoužitelný.

Problém s údržbou bude třeba vyřešit, než dojde k začlenění LibOS do kernelu. Pokud bude často rozbitý, vývojáři ho nebudou používat. Nepoužitelnost povede ke stížnostem na maintainery pracující na vlastním kódu, a ti mohou volat po jeho odstranění. Aby se dalo předejít těmto nástrahám, je třeba najít nějaký způsob, který by automatizoval vytváření stub funkcí. Vytvoření (verze) módu knihovny kernelu by mohlo být snadné, zvlášť když vezmeme v úvahu, co je zapotřebí, aby vše fungovalo v dlouhodobém horizontu.

       

Komentáře

[Michal Kubeček]

Zajímalo by mne, jestli DaveM viděl funkci send_dg() v glibc a celý chain, který k ní vede. Ale s Ulrichem Drepperem asi chce být kamarád málokdo. :-)

[pc2005]

printk

[Petr Tomášek]

séťové topologie

Ať žijó brňáci!