Portál AbcLinuxu, 24. prosince 2025 12:15
Jaderné noviny – 3. 3. 2010
Články
-
Jaderné noviny – 3. 3. 2010
Začleňovací okno 2.6.34. Citáty týdne: Linus Torvalds, Andrew Morton. Vydán Linux 2.6.33-libre. Nové vlastnosti a výchozí nastavení. Rozvod jmenných prostorů a procesů. Co tu smrdí rybinou? Začleňovací okno 2.6.34, část první. SCALE 8x: Vývojový proces jádra Ubuntu.
Obsah
Začleňovací okno 2.6.34
link
Začleňovací okno 2.6.34 je otevřené, nejsou tedy žádné vývojové verze tohoto jádra. Níže vizte samostatný článek, který shrnuje, co bylo zatím do 2.6.34 začleněno.
Během minulého týdne nevyšly žádné stabilní aktualizace, ani se žádné nerevidují.
Citáty týdne: Linus Torvalds, Andrew Morton
link
Takže pánové: Základní bod klidně měňte [rebase]. Ale když to uděláte, tak týden počkejte. Vyhněte se „změním základní bod a pak požádám Linuse, aby to přetáhl“. To je prostě špatně, znamená to, že mě žádáte, abych přetáhl strom, který nebyl vůbec testován.
-- Linus Torvalds
Jej, tohle makro je potřeba umlátit klackem dřív, než si uvědomí samo sebe a začne se množit.
-- Andrew Morton se nás snaží všechny zachránit.
Vydán Linux 2.6.33-libre
link
Free Software Foundation Latin America oznámila vydání distribuce jádra 2.6.33-libre. Linux není svobodný software od roku 1996, kdy pan Torvalds přijal do Linuxu první kousky nesvobodného softwaru, poprvé od roku 1991. Zatímco jádro se během let zvětšilo čtrnáctkrát, množství nesvobodného firmware vyžadovaného linuxovými ovladači vzrostlo 83krát, což je alarmující. My, uživatelé svobodného softwaru, musíme spojit své síly, abychom tento trend zvrátili; součástí řešení je Linux-libre, jehož verzi 2.6.33-libre právě vydala FSFLA, přináší svobodu, značná zlepšení a plány do budoucna. Jejich motivaci a metodám je věnováno mnoho slov, ale v oznámení se nedostali k tomu, aby řekli, kde sehnat balík; uživatelé, kteří mají zájem, by se měli poohlédnout na fsfla.org.
Celý článek na LWN.net.
Nové vlastnosti a výchozí nastavení
link
napsal Jonathan Corbet, 3. března 2010
U každého začleňovacího okna se objeví téma nebo dvě, která se obvykle týkají toho, „jak nezačleňovat kód“. Tentokrát jsou na pořadu dne konfigurační volby; objevilo se několik nových vlastností, jejichž konfigurační volby byly ve výchozím nastavení přepnuty na „ano“. To je proti zavedeným způsobům a Linuse to štve. Jeho slovy:
Ale jestli to není stará vlastnost, která předtím neměla konfigurační volbu, a neléčí to rakovinu, nikdy NIKDY se nesmí objevit „default y“. Protože když udělám „make oldconfig“ a vidím výchozí hodnotu „Y“, řeknu „tuhle sr*čku přetahovat nebudu“.
Sdělení je jasné: Nové vlastnosti, které míří do hlavní řady, by neměly být ve výchozím nastavení zapínány.
Rozvod jmenných prostorů a procesů
link
napsal Jonathan Corbet, 3. března 2010
Během několika uplynulých let vývojová komunita zaměřená na implementaci kontejnerů do jádra přidávala různé jmenné prostory. Každý jmenný prostor obaluje jeden globální jaderný zdroj (jako je síťové prostředí, seznam běžících procesů nebo strom souborového systému), což dovoluje, aby měl každý kontejner jiný pohled na daný zdroj. Jmenné prostory jsou těsně spojeny se stromy procesů; jsou vytvářeny s novými procesy pomocí zvláštních příznaků systémového volání clone(). Když je vytvořen, je jmenný prostor viditelný pouze pro nově vytvořené procesy a jejich potomky a existuje jenom do doby, dokud existují tyto procesy. To v mnoha situacích postačuje, ale v jiných by bylo hezké mít déle žijící jmenné prostory, které jsou přístupné rychleji.
Za tímto účelem Eric Biedderman navrhl vytvoření dvou nových systémových volání. První je poměrně zkratkovitě nazváno nsfd():
int nsfd(pid_t pid, unsigned long nstype);
Systémové volání najde jmenný prostor daného nstype, který je platný pro proces identifikovaný pomocí pid; vrácená hodnota bude popisovač souboru, který identifikuje daný jmenný prostor a drží na něj odkaz. Aby volání uspělo, musí mít volající proces možnost použít ptrace() na daný pid; v současném patchi jsou podporovány jenom síťové jmenné prostory.
Jednoduché držení daného otevřeného popisovače souboru stačí k tomu, aby cílový jmenný prostor nezanikl, i když se všechny procesy v něm ukončí. Jmenný prostor lze zviditelnit vytvořením vázaného připojení [bind mount] takto:
mount --bind /proc/self/fd/N /někam
Dalším kouskem skládačky je setns():
int setns(unsigned long nstype, int fd);
Toto systémové volání změní jmenný prostor daného procesu tak, že se novým jmenným prostorem stane prostor s daným fd. To řeší problém vstupu do jmenného prostoru jiného kontejneru bez poněkud podivné sémantiky kdysi navrhovaného systémového volání hijack().
Tato nová systémová volání jsou v počátečním stavu, ve kterém prokazují svou použitelnost, takže se pravděpodobně významně změní na své cestě do 2.6.35, kam je mířeno jejich začlenění.
Co tu smrdí rybinou?
link
napsal Jonathan Corbet, 3. března 2010
O přítomnosti kódu Androidu v hlavní řadě, respektive o jeho nepřítomnosti, proběhlo mnoho diskuzí. Absence Androidu má mnoho důvodů včetně toho, že se vývojářský tým více než na začlenění do upstreamu zaměřuje na blížící se vydání handsetu a že se objevily významné neshody týkající se technických záležitostí okolo kódu. Nějakou dobu se zdálo, že se objeví další překážka: Soubory se zdrojovými kódy pojmenované podle ryby.
Jako většina produktů i handsety Android měly předtím, než skončily v obchodech, mnoho kódových označení. Daniel Walker citoval příklad: Handset HTC, který byl výrobcem pojmenován „Passion“ [vášeň]. Když ho získal Google pro práci na Androidu, usoudili, že by pro něj mohlo být dobré jméno „Mahimahi“. Až v konečných fázích vývoje získal jméno „Nexus one“. Značka „nečistě porušující práva Applu“ přišla ještě později.
Daniel se ptal: Jaké jméno by mělo být použito, až bude tento kód portován do hlavní řady? Vývojáři v Googlu, kteří napsali kód, použili jméno „mahimahi“, takže strom zdrojových kódů je plný souborů jako board-mahimahi-audio.c; ty sedí vedle souborů pojmenovaných podle pstruha, platýze či mečouna. Daniel si myslí, že tato jména by mohla být matoucí; z tohoto důvodu se z board-trout.c stalo board-dream.c, když byl přesouván do hlavní řady. Koneckonců jenom málo uživatelů G1/ADP1 má za to, že si po kapsách nosí pstruhy.
Problém je samozřejmě v tom, že toto přejmenovávání ztěžuje život lidem, kteří se snaží přesouvat kód mezi hlavní řadou a stromy Googlu. Vzhledem k překážkám, které na této cestě již existují, se nezdá, že by někdo volal po tom, aby byly věci složitější. Správce ARM k takovému závěru došel a prohlásil:
Když dojde na přesouvání tohoto kódu do hlavní řady, stále toho nemáme moc, co bychom mohli ukázat – nepřidávejme do cesty další bariéry.
Zatím ponechme současné pojmenovávání a připravme do souborů informativní komentáře o těch druhých jménech, v Kconfigu použijeme společné jméno – tak bude z pohledu konfigurace jádra zjevné, co je nutné pro danou platformu vybrat, a vyhneme se tím situaci, kdy bychom efektivně měli dvě základny kódu.
Podle všeho to diskuzi ukončilo; kód Androidu na úrovni základní desky si může nechat svoje rybí jména. To samozřejmě nepomůže, pokud kód nebude mířit do hlavní řady ani tak. Dobrá zpráva je, že se lidé nevzdali a pracuje se na tom, aby se tak stalo. Při troše štěstí bude instalace jádra hlavní řady na mečouna jednoduchým úkolem pro každého.
Začleňovací okno 2.6.34, část první
link
napsal Jonathan Corbet, 3. března 2010
V době psaní tohoto článku je otevřeno začleňovací okno 2.6.34, zatím bylo akceptováno 4480 neslučujících sad změn. Jako obvykle dlouho trpící (čtěte pomalu se učící) autor článku pročetl všechny, aby mohl vytvořit toto shrnutí nejzajímavějších změn. Začněme změnami viditelnými pro uživatele:
Byly začleněny patche pro asynchronní uspávání a probouzení, což snad povede k lepšímu využívání energie. Byl přidán přepínač (/sys/power/pm_async), který umožňuje globální vypínání a zapínání této vlastnosti; také byly přidány samostatné přepínače pro jednotlivá zařízení.
Nový příkaz „perf lock“ generuje statistiky využívání zámků a soupeření o ně.
Do nástroje perf byla přidána podpora skriptování v Pythonu.
Body pro dynamické sledování lze nyní vkládat podle čísel řádků i podle pozice v bytech.
Architektura SuperH získala podporu pro tříúrovňové tabulky stránek, jádra komprimovaná pomocí LZO a vylepšené hardwarové body přerušení [breakpoints].
Z kódu architektury ia64 (Itanium) byla odebrána podpora pro spouštění 32bitových x86 binárek. Evidentně dva roky nefungovala a nikdo si toho nevšiml.
Bylo přidáno virtuální zařízení „vhost_net“. Podobně jako kdysi navrhované systémové volání vringfd() umožňuje vhost_net efektivní síťové spojení ve virtualizovaných prostředích.
Síťová vrstva nyní podporuje RFC5082 „Bezpečnostní mechanismus se zobecněným TTL“, což je ochrana pro protokol BGP proti útoku odepření služby.
Susbystém netfilteru nyní podporuje sledování spojení u TCP SIP spojení.
Kód DECnet osiřel, což znamená, že již nemá správce. Podle všeho převažuje názor, že zbývá jenom málo nebo žádní uživatelé tohoto kódu. Pokud jsou uživatelé, kteří mají zájem o podporu DECnet v současných jádrech, měli by o sobě ve vlastním zájmu dát vědět.
Do kódu pro síťový bridge byla přidána podpora pro IGMP snooping; tato podpora umožňuje výběrové přeposílání mulitcastového provozu.
Mezi změny viditelné pro vývojáře jádra patří:
Vrstva virtio získala mnoho nových vlastností, které mají za cíl vylepšit výkonnost a efektivitu virtualizovaných systémů. Mezi jinými je zde nový mechanismus pro statistiky paměti, který hypervizoru umožňuje chytřeji přizpůsobovat velikosti pamětí. Také byla přidána pro topologii bloků, což vede na efektivnější blokové I/O.
Vrstva interakce s uživatelem [human interface layer] byla rozšířena tak, aby zvládla zařízení s opravdu obrovským počtem tlačítek.
Dlouho zastaralá funkce pci_find_device() byla odstraněna společně s konfigurační volbou CONFIG_PCI_LEGACY.
Byly přidány dvě nové funkce – flush_kernel_vmap_range() a invalidate_kernel_vmap_range(), které umožňují bezpečně používat DMA na oblastech paměti alokovaných vmalloc(). Detaily vizte v Documentation/cachetlb.txt.
Byly začleněny patche lockdep pro RCU, což umožňuje automatizovanou kontrolu zamykání RCU na straně čtenáře.
Nová funkce
list_rotate_left(struct list_head *head);
rotuje seznam o jeden prvek doleva
Přistupující [accessor] funkce blk_queue_max_sectors() byla přejmenována na blk_queue_max_hw_sectors().
Události výkonnosti jsou nyní podporovány i na procesorech ARMv6 a ARMv7.
Vstupní zařízení nyní mohou mít funkce filter(), ty lze použít k odfiltrování specifických událostí, kter0 se tak nedostanou do uživatelského prostoru. Také je zde nová funkce match(), která ovladačům dává lepší kontrolu nad přiřazováním zařízení k jejich obsluhám.
Vrstva i2c má podporu pro SMBus „poplachy“ [alerts], kde několik slave zařízení sdílí jeden pin pro přerušení, ale i tak je možné sdělit, který slave přerušil.
Začleňovací okno je běžně otevřené dva týdny, ale Linus naznačil, že tentokrát může být o něco kratší. Takže je možné, že až příští týden vyjdou Jaderné noviny, bude začleňovací okno již uzavřené a seznam vlastností 2.6.34 kompletní. V takovém případě si nás nalaďte a najdete shrnutí druhé poloviny začleňovacího okna.
SCALE 8x: Vývojový proces jádra Ubuntu
link
napsal Jake Edge, 3. března
Manažer pro jádro v Canonicalu Pete Graner hovořil na UbuCon – který se konal těsně před SCALE 8x – o „Vývojovém procesu jádra v Ubuntu“. Ve své přednášce mluvil o tom, jak se Ubuntu rozhoduje o tom, co bude v jádře a jak bude jádro překládáno a testováno. Poskytl zajímavý pohled na tento proces zevnitř, přičemž výsledkem tohoto procesu je nové vydání jádra pro každou novou verzi Ubuntu, která vychází jednou za šest měsíců.
Pete v Canonicalu řídí docela velkou skupinu, celkem 25 lidí, kteří se dělí do dvou podskupin – jedna se zaměřuje na jádro samotné a druhá na ovladače. U každého vydání jaderný tým vybere „vedoucího vydání jádra“ [kernel release lead, KRL], který je zodpovědný za to, aby jádro bylo připraveno na vydání a na své uživatele. Funkce KRL se střídá mezi jednotlivými členy týmu, Andy Whitcroft má na starosti Lucid Lynx (10.04) a Leann Ogasawara má být KRL pro následující verzi („M“ či 10.10).
Šestiměsíční vývojový cyklus je velice náročný, řekl Pete. Tým musí být velmi opatrný, co se týče toho, které ovladače – ve stromě, ve staging, mimo strom – budou povoleny. Tým pravidelně vezme některé ovladače ze stromu Staging a před zapnutím ve stromě Ubuntu je trochu opraví, takže uživatelé Ubuntu mají k dispozici lepší pokrytí hardwaru.
Jakmile je zmrazeno vydání jádra k vydání, vytváří se větev pro další vydání. Kupříkladu jádro pro Lucid bude zmrazeno během několika týdnů, přičemž se vytvoří větev pro verzi 10.10. Tato větev bude jádro „na ostří nože“ ze stromu Linuse Torvaldse (pravděpodobně 2.6.34-rc1) a tým začne další patche přidávat k této větvi.
Patche, které jsou takto přidány do stromu, zahrnují věci z linux-next (např. opravy uspávání/probouzení), patche, které do svého jádra přidal Debian, pak sada patchů specifická pro Ubuntu. Pokud jsou některé z nich začleněny do hlavní řady, lze je ze seznamu vyhodit, což je ale časově velice náročné, protože je potřeba projít gitový strom a vyřešit to. S každou značkou [tag] Linusova stromu dělají git rebase – vývojový strom není sdílen – najdou konflikty a vypořádají se s nimi.
Zaměření a směr jádra Ubuntu, stejně jako všechny ostatní vlastnosti Ubuntu, jsou určovány na Summitu vývojářů Ubuntu [Ubuntu Development Summit, UDS], který se koná krátce po každém vydání a kde se stanovují cíle a plány pro další verzi. Před UDS jaderný tým vytvoří nějaká širší témata a sepíše plány do wiki, kde tato témata popisuje. V minulosti se zaměřovali na věci jako uspávání/probouzení, síťování WiFi a zvuk; velké téma, na kterém se pracuje, je správa napájení, řekl Pete.
Specifikace těchto vlastností má podobu vysokoúrovňových hrubých popisů (např. John má laptop a chce 10 hodin životnosti na baterie). Popisy jsou přetvořeny v různé případy použití, které následně vedou na plán. Všechny diskuze, rozhodnutí, plány a podobné jsou zachyceny na wiki UDS.
Jedna z delších debat se na UDS dívá na konfigurační volby v jádře (tj. na jaderný soubor .config) a určuje se, které by měly být povoleny. Nové možnosti jsou podrobně zkoumány a rozhoduje se, jestli je taková vlastnost zapotřebí, ale dřívější rozhodnutí jsou zkoumána také.
Pete navíc řekl, že se tým dívá na patche a ovladače, které byly do minulého jádra přidány, a zabývá se tím, jestli je v příští verzi ponechat. Jako na problematickou vlastnost poukázal na Aufs, který se s každou novou verzí jádra rozbije a trvá až tři týdny ho rozchodit. Mluvili o tom, že by se ho zbavili, protože Linus ho do hlavní řady nezačlení, ale live CD ho potřebují.
Jaderný tým musí udržovat v rovnováze potřeby komunity Ubuntu stejně jako obchodní záležitosti Canonicalu kvůli věcem, jako je například Ubuntu One, a musí přijít s takovou sadou vlastností, které uspokojí obě skupiny. Diskuze o tom, co se do jádra dostane, občas na UDS bývají poměrně rozvášněné; Pete řekl, že Lucid byl docela v klidu, ale Karmic byl poněkud rušný.
Lucid bude dodáván s jádrem 2.6.32, což pro vydání s dlouhodobou podporou [long-term support, LTS] dává smysl. 2.6.32 bude podporováno jako stabilní vydání několik dalších let a bude dodáváno s příštím RHEL a SLES. To znamená, že se mu dostane lepšího pokrytí testováním, což u Lucid povede na velmi stabilní jádro.
Každá aktualizace stabilního jádra je přetažena do jaderného stromu Ubuntu, ale LTS aktualizace budou tlačeny do hlavní řady pouze čtvrtletně, pokud se nebude jednat o bezpečnostní opravu důležitosti „vysoká“ nebo „střední“. Co se týče vývoje nových vlastností, tým přetahuje i vydání hlavní řady jádra a kandidáty na vydání [release candidate]. Pete udal dva příklady nového vývoje, který probíhá v jaderných stromech Ubuntu: Přidání podpory stromu zařízení [device tree] do architektury ARM, což omezí složitost podpory několika jader pro ARM, a bezpečnostní modul AppArmor, který míří do jádra 2.6.34.
Jakmile je verze jádra zmrazena pro vydání, správa tohoto jádra je kontrolována mnohem přísněji. Aplikovány jsou jedině patche, se kterými je spojena nějaká chyba. Z patchů ve stabilním jádře se vybírá podle problémů uživatelů a bezpečnostních záležitostí. Na plný úvazek pracuje posuzovatel jaderných chyb, který se pokouší určit, zda ohlašovatel chyby zahrnul dostatek informací, aby byla nějaká naděje na to, že bude problém nalezen – jinak je chyba zahozena. Je však jeden způsob, jak zajistit, že chyba opravena bude – ukázat upstreamu patch, který problém opravuje; takový je přetažen do jádra, řekl Pete.
Existují zmrazené verze pro každé alfa, beta a konečné vydání, ale v době zmrazení musí jádro už být v archivu. Pokaždé, když je jádro zmrazeno, trvá téměř týden přeložit všechny architektury, které Ubuntu podporuje. Ubuntu podporuje víc architektur, než jakákoliv jiná distribuce, alespoň podle toho, co je Petovi známo. Každý překlad probíhá ve virtualizovaném prostředí se specifickou sadou nástrojů, který lze použít opakovaně, pokud je potřeba přeložit aktualizaci. To vše znamená, že jádro musí být zmrazeno před zmrazením vydání obecně, typicky o měsíc dřív.
Jakmile je jádro připraveno, testuje se v Montrealu v laboratoři s 500 či 600 stroji. QA tým zkouší jádro na veškerém hardwaru, což je také proces, který nějaký čas trvá. Dříve byla jádra hozena přes zeď uživatelům, aby je otestovali, ale Canonical se teď víc snaží dělat to lépe tak, že věnuje testování a QA více zdrojů.
Spravovat jaderná vydání pro distribuce je velká úloha a detaily tohoto procesu obecně nejsou dobře známy. Petova přednáška to pomohla změnit, což by mělo umožnit jiným se do tohoto procesu více zapojit. Pochopení toho, jak vše funguje, pomůže lidem mimo tým lépe s týmem spolupracovat, což by mělo vést na lepší jádra pro uživatele Ubuntu.
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
30.3.2010 07:58
ewqrqwr
Re: Jaderné noviny – 3. 3. 2010
30.3.2010 08:19
trekker.dk | skóre: 72
Re: Jaderné noviny – 3. 3. 2010
30.3.2010 09:33
Jakub Lucký | skóre: 40
| Praha
Re: Jaderné noviny – 3. 3. 2010
30.3.2010 10:51
Kaacz | skóre: 10
| Praha 4
Re: Jaderné noviny – 3. 3. 2010
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
To jen dokazujue, že Greg Kroah-Hartman má pravdu a trefil do černého, zatím co hysterické reakce Canonicallu jsou jen kdákáním potrefené husy.
31.3.2010 10:31
Jardík | skóre: 40
| blog: jarda_bloguje
31.3.2010 23:30
30.3.2010 14:30
30.3.2010 09:33
30.3.2010 17:54
31.3.2010 07:33
30.3.2010 10:51