Jaderné noviny - 12. 4. 2006

24. 4. 2006 | Robert Krátký | Jaderné noviny | 5133×

Aktuální verze jádra: 2.6.16.5. Kontejnery a odlehčená virtualizace. Systémová volání tee() a splice(). Zachování údajů o oops při resetu. Neostré hranice GPL.

Aktuální verze jádra: 2.6.16.5

Aktuální verze stabilního jádra je 2.6.16.5. Byla vydána 7. dubna s početnou řádkou oprav; 2.6.16.3 a 2.6.16.4 - z nichž každá obsahuje jen jedinou bezpečnostní opravu - vyšly obě 11. dubna a 2.6.16.5, se dvěma opravami pro x86-64, byla vydána 12. dubna.

Aktuální předverze je i nadále 2.6.17-rc1; během minulého týdne žádné další předverze nevyšly. 2.6.17-rc2 je však zjevně na spadnutí a v době, kdy tohle čtete, už je možná venku.

Patche začleněné od 2.6.17-rc1 jsou většinou opravy, ale najde se i několik významnějších změn, včetně zjednodušené formy patche pro předcházení hladovění scheduleru, vyladění algoritmu používaného při přetížení paměti [memory overcommit], odstranění nespravovaných ovladačů blkmtd a Sangoma WAN a změn v systémovém volání splice().

Aktuální -mm strom je 2.6.17-rc1-mm2. Mezi nedávné změny patří nová sada patchů pro sledování zdrojů na 64bit a úpravy kódu pro výpis jádra [core dump].

Kontejnery a odlehčená virtualizace

"Virtualizace" spočívá v přesvědčení skupiny procesů o tom, že má pro sebe vyhrazený systém. K problému virtualizace je přistupováno několika způsoby, přičemž Xen, VMWare a User-mode Linux patří mezi ty známější možnosti. Jde však o relativně těžkotonážní řešení, protože pro každý virtuální stroj je spouštěno samostatné jádro. To je často vhodným řešením; provoz nezávislých jader zaručuje pevné oddělení jednotlivých prostředí a umožňuje spuštění více operačních systémů na jednom hardwaru.

Plná virtualizace a paravirtualizace ale nejsou jedinými způsoby. Alternativou je odlehčená virtualizace, která bývá založena na nějakém druhu kontejnerového konceptu. V případě kontejnerů to vypadá, jako by skupina procesů i tak měla svůj vyhrazený systém, ale ve skutečnosti běží ve speciálně izolovaném prostředí. Všechny kontejnery jsou spuštěny nad jediným jádrem. Při použití kontejnerů je ztracena možnost provozovat různé operační systémy a oddělení virtuální systémů také není tak pevné. Na druhou stranu mají kontejnery nezanedbatelné výhody z hlediska výkonu, takže jich může být na jednom fyzickém hostiteli spuštěn velký počet.

Kontejnerových projektů rozhodně není nedostatek. Řadí se mezi ně relativně prosté způsoby, například BSD jail module, ale také propracovanější - například Linux-VServer, OpenVZ a proprietární Virtuozzo (založený na OpenVZ). Mnohé z těchto projektů by rády protlačily alespoň nějaký kód do jádra, aby se zbavily břemene udržování patchů mimo hlavní strom. Není však velký zájem o začlenění kódu, který podporuje jen některé z těchto projektů. Lidé zabývající se kontejnery se budou muset dohodnout na společných řešeních, která by mohli používat všichni.

A vypadá to, že přesně o to se snaží. Začala platit volná dohoda, v jejímž rámci budou vývojáři z několika projektů diskutovat o navrhovaných změnách a snažit se je dostat do stavu, který by vyhovoval potřebám všech. Jakmile se konkrétní patch dostane tak daleko, že jej budou všichni vývojáři ochotni odsouhlasit, bude přeposlán k začlenění do hlavního jádra.

Zdá se, že komplexnější a náročnější změny, jako třeba virtualizace PID, jsou prozatím pozastaveny. Místo toho to vypadá, že prvním společně odsouhlaseným patchem bude virtualizace jmenného prostoru UTS. Cíl patche je poměrně přímočarý: umožňuje každému kontejneru (reprezentovanému stromem procesů) mít vlastní verzi struktury utsname, která bude držet jméno uzlu, jméno dmény, verzi operačního systému a pár dalších věcí. V podstatě to nahrazuje jedinou globální strukturu několika strukturami připojenými na různá místa stromu procesů. Je k tomu potřeba pětidílný patch, který nahradí každou zmínku o globální struktuře system_utsname voláním nové funkce utsname().

Dlouhodobé plány mluví o virtualizaci všech globálních jmenných prostorů v jádře - včetně SYSV IPC, ID procesů a dokonce pravidel netfilteru. O virtualizaci bezpečnostních modulů proběhla zajímavá diskuze; někteří si myslí, že každý kontejner by měl mít možnost nahrát svou vlastní bezpečnostní politiku, zatímco další argumentují ve prospěch jediného systému bezpečnostní politiky, který si je kontejnerů vědom (a je schopen je využívat). Nepřekvapí, že SELinux už je vybaven mechanismem pro hierarchii typů, který může být s kontejnery používán při řešení s jednotnou bezpečnostní politikou.

Některé vývojáře ještě možná bude těžké o kontejnerech přesvědčit, protože v nich budou spatřovat komplikaci pro přístup k mnoha interním datovým strukturám jádra, aniž by přinášely nějak moc výhod. Je však zřejmé, že po tomto druhu odlehčené virtualizace existuje poptávka - samotné OpenVZ tvrdí, že provozuje přes 300 tisíc virtuálních prostředí. Takže tlak na standardizaci kódu a přesunutí do hlavního jádra bude časem ještě sílit. Až bude kód dostatečně čistý, aby s ním byla vývojářská komunita spokojena, je pravděpodobné, že budou části kontejnerového konceptu začleněny.

Systémová volání tee() a splice()

O novém systémovém volání splice() byla řeč minulý týden. Jak jsme očekávali, nové API prošlo dalším vývojem; mnohé z patchů, které neobsahovaly opravy chyb, se týkaly změn v splice().

Především se změnil prototyp splice():

    long splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out,
                size_t len, unsigned int flags);

Dvě nové offsetové hodnoty (off_in a off_out) označují, kde má být před začátkem přenosu dat umístěn popisvač souboru. Všimněte si, že tyto offsety jsou předávány ukazateli, takže uživatelský prostor může využít ukazatel NULL, a tím dát najevo, že má být použit aktuální offset. Také si všimněte, že tyto offsety nefungují stejně jako offsety v pread() nebo pwrite(): skutečně změní offset přiřazený k popisovači souborů. Zadání offsetu pro popisovač souboru přiřazený k rouře je chyba.

Samotnému kódu splice() se dostalo několika zajímavých změn. Jednou z nich (vlastně v kódu roury) je vytvoření nové struktury pipe_inode_info, která reprezentuje hlavní funkčnost roury. Tato struktura může být oddělena od běžné struktury inode. Mnohá interní rozhraní byla změněna tak, aby novou strukturu využívala. To se týká i nových metod ve struktuře file_operations:

    ssize_t (*splice_write)(struct pipe_inode_info *pipe, 
                            struct file *out, size_t len, 
			    unsigned int flags);
    ssize_t (*splice_read)(struct file *in, struct pipe_inode_info *pipe, 
                           size_t len, unsigned int flags);

Protože je implementací těchto metod v jádře pořád málo, nejde o příliš rušivé změny.

Další je na seznamu podpora pro přímé "splicování" dvou popisovačů souborů, z nichž ani jeden není roura. Tato funkčnost (zatím) není prostřednictvím splice() dostupná uživatelskému prostoru, ale interně je využívána k implementaci sendfile() se splice() mechanismem. Přímé "splicování" je implementováno pomocí skryté struktury pipe_inode_info (tj. roury); je uloženo v novém poli splice_pipe struktury úloh, takže každý proces může mít v určitý okamžik puštěno jen jedno takové spojení.

Jeden patch začleněn nebyl - a pravděpodobně si bude muset počkat až na 2.6.18 - systémové volání tee():

    long tee(int fdin, int fdout, size_t len, unsigned int flags);

Toto volání vyžaduje, aby oba popisovače souborů byly roury. Jednoduše propojí fdin na fdout a přenese mezi nimi až len bajtů. Na rozdíl od splice() však tee() nespolyká vstup, takže mohou být vstupní data volajícím procesem později normálně přečtena. Jens Axboe nabídl vzorovou implementaci uživatelské utility tee, která není nic než pár volání:

    len = tee(STDIN_FILENO, STDOUT_FILENO, INT_MAX, SPLICE_F_NONBLOCK);
    splice(STDIN_FILENO, out_file, len, 0);

Vstupní data budou zapsána jak na standardní výstup, tak do souboru určeného pomocí out_file, aniž by byla kdy kopírována z nebo do uživatelského prostoru. Aby se zajistilo zkopírování kompletního proudu vstupních dat, musí samozřejmě aplikace provádět výšezmíněná volání ve smyčce. Celý příklad najdete na konci patche s voláním tee().

Toto volání je docela nové a možná bude změněno, než se objeví v hlavním stromě. Kromě jiného by mohlo být přejmenováno, protože něco tak jednoduchého jako tee() už je možná použito v mnoha jiných aplikacích.

Wireless Networking Summit 2006

Reportáž o setkání vývojářů podpory pro bezdrátové síťování v Linuxu byla kvůli své délce vydána jako samostatný článek: Wireless Networking Summit 2006.

---

Následující obsah je © KernelTrap

Zachování údajů o oops při resetu

10. dub, originál

James Courtier se v konference LKML ptal, jestli je možné obnovit kruhový buffer jádra po resetu. Navrhl prostě zapsat data v mnoha kopiích do paměti a doufat, že při bootu nebude vymazána veškerá RAM, což umožní obnovu bufferu. Kruhový buffer jádra je obyčejně prohlížen pomocí příkazu dmesg. James přiblížil (přičemž se odkazoval na metodu, při které jsou údaje o oops sbírány přes sériovou linku): Něco takového by pomohlo hlavně u novějších základních desek, které nemají sériový port. Existující řešení je použít kexec k nabootování speciálního odlehčeného jádra, se kterým pak lze posbírat jaderný výpis o pádu.

Všeobecný názor byl, že data zapsaná do RAM před resetem už v ní po restartu nebudou, i když se diskutovalo o tom, kolik přesně paměti bude přepsáno. Eric Biederemann, autor kexec, vysvětlil: Vyčištění paměti lze provést nejvyšší podporovanou rychlostí, takže jsou to vteřiny. Na systémech s ECC je potřeba inicializovat všechny kontrolní bity, a proto nějaký zápis do paměti musí proběhnout. K tomu doplnil: V praxi reset paměť nečistí a jen pár bitů bude převrácených. Andi Kleen navrhl jiné řešení: Definuj obecné rozhraní, které ovladačům umožní registrovat obsluhovače pro ukládání do paměti [memory storage handlers]. Do funkcí, které při oops oznamují die a panic, přidej záznam, který jaderný log uloží do těchto záloh. Jako příklad Andi uvedl ovladače grafiky, které by mohly kousek RAM na kartě vyšetřit pro uchování údajů o pádu během restartu.

Neostré hranice GPL

12. dub, originál

Linus Torvalds vydal v září 1991 linuxové jádro nejprve s velmi omezující licencí, která vyžadovala, aby zdrojový kód zůstal vždy dostupný a nikdo na něm nevydělával peníze. O pár měsíců později přešel na GPL, neboli Všeobecnou veřejnou licenci - a od té doby už byla pro jádro použita vždy. Nedávná diskuze ve vývojářské konferenci se zabývala neostrými hranicemi legálnosti v oblastech, kde není zcela jasné, co GPL povoluje. Alan Cox byl jedním z mnoha vývojářů, kteří vysvětlovali:

Hranicí GPL je takzvané "odvozené dílo". To je základní právní koncept používaný v copyrightu, který klade otázku: "Je toto dílo vytvořeno takovým způsobem, aby bylo možné říci, že je založeno na původním díle?" Jde o komplikovanou oblast práva a pouze právník může dát definitivní odpověď.

"Aplikace pro Linux" je jasný případ. "Úprava jádra" je také jasná. Mezi tím je mlhavý prostor pro právníky.

       

Komentáře

[Lukáš Zapletal]

A co Solaris? Ten umí přece něco podobného. Jedná se o to samé (tedy odlehčenou virtualizaci), nebo je to něco úplně jiného?

[Vskutečnosti Saýc]

Je to odlehcena virtualizace. Navic ma zabudovanou podporu v balickovacim systemu a shelduleru jadra systemu, takze se ruznym kontejnerum da priradit pamet, daji se jim vyhradit ruzne procesory nebo jim nastavit kolik procesoroveho casu dostanou v pomeru s ostatnimi.

[Vašek Lorenc]

"SELinux už je vybaven mechanismem pro hierarchii druhů" -- v tomto případě bych neodporučoval "types" překládat jako druhy. SELinux využívá něco, co se jmenuje "domain and type enforcement" (DTE), což je i v překladu o typech a doménách, nikoliv o druzích.

[Robert Krátký]

Dík.