AbcLinuxu:/ Články / Jaderné noviny - 11. 6. 2008

Štítky: AbcLinuxu, distribuce

Jaderné noviny - 11. 6. 2008

30. 7. 2008 | Jirka Bourek | Jaderné noviny | 2941×

Aktuální verze jádra: 2.6.26-rc5. Nový jaderný strom: linux-staging. Shrnutí změn API v 2.6.26. Rozhovor: Andrew Morton o vývoji jádra.

Obsah

Aktuální verze jádra: 2.6.26-rc5
Nový jaderný strom: linux-staging
Shrnutí změn API v 2.6.26
Rozhovor: Andrew Morton o vývoji jádra

Aktuální verze jádra: 2.6.26-rc5

link

Současné vývojové jádro 2.6 je 2.6.26-rc5 vydané 4. června. Jako obvykle v této fázi vývojového cyklu obsahuje většinou opravy chyb a podobné. Je v něm slušné množství změn ve vnitřním jaderném kódu, nejvíce kvůli problémům s plánovačem, a zahrnuje několik revertů kvůli regresím výkonnosti. Další týden, další dávka většinou poměrně malých oprav. Doufejme, že se seznam regresí zmenšuje a že jsme opravili alespoň pár oopsů z Arjanova seznamu. Detaily najdete v dlouhém changelogu. Vydání 2.6.26-rc6 je pravděpodobně nasnadě.

Současná verze -mm stromu je 2.6.26-rc5-mm2, opravuje chyby v 2.6.26-rc5-mm1 a také byla vydána tento týden. Hlavním přírůstkem je strom neprivilegovaných připojení a velké množství hlubokých změn ve správě paměti.

Současné stabilní jádro 2.6 je 2.6.25.6 vydané 9. června. Obsahuje celou hromadu oprav chyb, z nichž žádná není specificky označována jako bezpečnostní. Obsahuje mnoho různých oprav chyb po celém stromě. Uživatelům je doporučeno aktualizovat. Vizte oznámení LWN, ve kterém najdete nějaké diskuze o potenciálních bezpečnostních problémech spojených s tímto vydáním. Také si všimněte, že 7. června bylo vydáno 2.6.25.5 s s jednou bezpečnostní opravou. Jestliže používáte CIFS nebo SNMP NAT, můžete být zranitelní a je vám doporučeno aktualizovat.

Co se týče starších jader: 6. června bylo vydáno 2.4.36.6. Opravuje jenom zranitelnost v ip_nat_snmp_basic modulu netfilteru (CVE-2008-1673). Jestliže tento modul nepoužíváte, nemusíte aktualizovat.

Nový jaderný strom: linux-staging

link

Ve městě je nový jaderný strom. Greg Kroah-Hartman oznámil strom linux-staging 10. června. Je určen pro ovladače a další jaderné patche, které se propracovávají do hlavní řady, ale stále musí ujít kus cesty. Záměrem je sesbírat je všechny dohromady do jednoho stromu, aby se k nim zjednodušil přístup a testování pro vývojáře, kteří mají zájem.

Podle Grega je linux-staging (nebo -staging, jak bude bezpochyby nazýván) následník Projektu ovladač pro Linux [Linux Driver Project] a vznikl proto, že byly stížnosti, že pro jednotlivé ovladače není žádné místo, kde by mohly sedět, zatímco jsou pročišťovány a přiváděny do stavu, kdy je bude možné začlenit. Shromáždění těchto patchů na jedno místo je pro jadernou komunitu zviditelní a potenciálně může přitáhnout více vývojářů, aby pomohli s opravami, revizemi a testováním.

Záměrem -staging je uchovávat samostatné patche - Greg zmiňuje ovladače a souborové systémy - které by neměly ovlivnit nikoho, kdo je nepoužívá. Z toho důvodu doufá, že by -staging mohl být začleňován do stromu linux-next. Jak řekl Stephenu Rothwellovi, správci -next, v oznámení:

Ano, vím, že [linux-staging] obsahuje věci, které nebudou zahrnuty v dalším vydání, ale začlenění a základní testování překladem, které poskytuje tvůj strom, je nedocenitelné. Můžeš to přidat jako poslední a pokud bude jenom náznak problému v jakémkoliv patchi, máš mé plné svolení zahodit je na podlahu a s křikem utéci (a dát mi vědět, abych to mohl opravit).

Strom -next je určen pro věci, které míří k začlenění to jádra "N+1" (kde 2.6.N je verze, která je právě vyvíjena), takže začleňování kódu, který není určen k vydání, znamená nepatrné ohnutí pravidel. V době psaní tohoto článku Stephen Rothwell na požadavek zahrnout -staging neodpověděl, ale daným patchům by širší publikum rozhodně prospělo - s pouze malým dopadem na -next. Pro patche není stanovena žádná časová osa, během které by se měly ze -staging dostat do hlavní řady; Greg řekl:

Podle toho, kolik práce je potřeba na některých z těchto ovladačů, to bude rozhodně trvat déle než do N+2, pokud se neobjeví lidé, kteří by s tou prací pomohli. V podstatě se všude jedná o údržbářskou práci, ale já osobně vím, že nemám dost času na to, abych ji udělal všechnu, takže by se mi pomoc hodila.

Strom -staging je považován za skvělé místo pro Jaderné údržbáře [Kernel Janitors] a další, kteří se chtějí dozvědět o vývoji jádra a někde začít. Oznámení říká: Kód v tomto stromě zoufale potřebuje pročištění a opravy, které mohou být triviálně nalezeny pomocí sparse a scripts/checkpatch.pl. V tomto procesu pročišťování kódu se lidé mohou naučit, jak vytvářet patche a jak je nechat akceptovat do stromu. Naděje je taková, že odtud budou pokračovat ke složitějším úkolům - s kódem ve -staging nebo jinde - což povede k novému náběru jaderných hackerů.

Současný stav -staging ukazuje 17 patchů, většina z nich jsou ovladače z LDP. Greg aktivně podporuje zasílání dalšího kódu do -staging, pokud splňuje určitá stanovená kritéria. Strom není určen jako skládka pro ovladače, které někdo "hodil přes zeď" s nadějí, že si s nimi někdo jiný poradí. Také není určen pro kód, na kterém nějaká skupina vývojářů pracuje v nějakém jiném stromě - jako příklad je zmíněn souborový systém reiser4 - je určen pro kód, který by jinak odumřel.

Reakce na linux-kernel byly zatím příznivé, byly kladeny otázky o tom, jaké patche jsou pro nový strom vhodné, hlavně co se nových architektur týče. Strom -staging zaplňuje mezeru, která ještě nebyla pokryta ostatními stromy. Také slouží několika účelům od poskytnutí startovního bodu pro nové vývojáře po dodatečné testování a revidování nových ovladačů a dalšího kódu. S trochou štěstí urychlí příchod nových vlastností - a s tím i nových vývojářů.

Shrnutí změn API v 2.6.26

link

Vývojový cyklus 2.6.26 se stabilizoval do té míry, že je možné podívat se na interní změny API, ke kterým došlo. Ty zahrnují:

Do x86 byla konečně přidána podpora pro interaktivní debugger KGDB. V adresáři Documentation je DocBook dokument, který popisuje, jak tento nový nástroj používat. Některé užitečné vlastnosti (např. KGDB přes Ethernet) ještě nejsou podporovány, ale jde o dobrý začátek.
Pro x86 je také (opět - konečně) k dispozici podpora pro tabulky atributů stránek [Page attribute table, PAT]. PAT umožňují jemnější kontrolu cachování paměti s větší flexibilitou, než umožňovala MTRR. Více informací vizte v Documentation/x86/pat.txt.
ioremap() na architektuře x86 nyní vždy vrátí necachované mapování. Dříve se používal uvolněnější přístup a cachování bylo ponecháno tak, jak ho nastavil BIOS. Praktickým výsledkem bylo téměř vždy necachované mapování, ale s občasnými výjimkami. Ovladače, které závisí na cachovaném mapování, se nyní rozbijí; budou muset použít ioremap_cache(). Více informací o této změně a cachování obecně vizte v článku Učíme se zacházet s cachováním.
Byl začleněn patch obecných semaforů. Kód semaforů také má dvě nové funkce down_killable() a down_timeout().
Poslední uživatelé struct class_device byli konvertováni, aby místo toho používali struct device. Struktura class_device byla odstraněna společně se s ní spojenou infrastrukturou.
Operace nopage() na oblasti virtuální paměti byla odstraněna; veškerý kód ve stromě nyní místo ní používá fault().
Byla začleněna infrastruktura ladění objektů.
Pro podporu bezpečnostních modulů a kód auditu byly přidány dvě nové funkce (inode_getsecid() a ipc_getsecid()), které poskytují obecný přístup k bezpečnostním ID spojeným s inody a IPC objekty. Mnoho LSM callbacků spojených se superbloky má nyní místo ukazatele na struct path jako parametr ukazatel na struct nameidata. Také je nová sada háčků, které poskytují podporu pro obecný audit ve frameworku bezpečnostních modulů.
Nyní nepoužívaná MAC vrstva ieee80211 byla odstraněna; všechny ovladače, které ji potřebovaly, byly konvertovány na mac80211. Také byly odstraněny síťový ovladač sk98lin (ve prospěch skge) a bcm43xx (nahrazen b43 a b43legacy).
Struktura ata_port_operations, používaná libata ovladači, nyní podporuje jednoduché dědění operací, což zjednodušuje psaní ovladačů, které jsou "skoro stejné" jako existující kód, ale s malými změnami.
Nová funkce (ns_to_ktime()) konvertuje časovou hodnotu v nanosekundách na ktime_t.
Greg Kroah-Hartman již není správcem PCI subsystému, tuto odpovědnost předal Jesse Barnesovi.
Kód seq_file nyní akceptuje návratovou hodnotu SEQ_SKIP z callbacku show(); tato hodnota způsobí, že veškerý výstup nashromážděný z tohoto volání bude zahozen.
API Video4Linux2 nyní definuje sadu ovládacích prvků pro kamery; umožňují uživatelskému prostoru pracovat s parametry jako typ expozice, naklánění a otáčení, ostření a dalšími.
Pro architekturu x86 je k dispozici nová konfigurační volba, která gcc umožní se samostatně rozhodnout o inlinování funkcí i u funkcí, které jsou deklarovány jako inline. V některých případech může tato volba redukovat velikost kódového segmentu jádra o více než 2 %.
Stará IDE vrstva prošla mnoha interními změnami, které rozbijí všechny zbývající IDE ovladače mimo strom.
Stav, který spustí varování z WARN_ON, nyní také poskvrní [taint] jádro.
Rozhraní get_info() pro /proc soubory bylo odstraněno. Také je nová funkce pro vytváření těchto souborů:
```
struct proc_dir_entry *proc_create_data(const char *name, mode_t mode,
                                       struct proc_dir_entry *parent,
                                       const struct file_operations *proc_fops,
                                       void *data);
```
Tato verze přidává ukazatel data a zajišťuje, že bude nastaven ve výsledné struktuře proc_dir_entry předtím, než se uživatelský prostor může pokusit k ní přistoupit.
Typ klist (kseznam) má nyní pro deklaraci a inicializaci makra v obvyklé formě: DEFINE_KLIST() a KLIST_INIT. Dvě nové funkce (klist_add_after() a klist_add_before()) mohou do klistu přidávat záznamy na specifikovanou pozici.
kmap_atomic_to_page() již není exportována modulům.
Jsou k dispozici nové obecné funkce pro provádění 64bitového celočíselného dělení v jádře:
```
u64 div_u64(u64 dividend, u32 divisor);
u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder);
s64 div_s64(s64 dividend, s32 divisor)
s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder);
```
Narozdíl od do_div() je u těchto funkcí explicitně udáno, jestli se jedná o znaménkovou nebo bezznaménkovou matematiku. Pro x86 specifická funkce div_long_long_rem() byla odstraněna ve prospěch těchto nových funkcí.
Je zde nová řetězcová funkce:
```
bool sysfs_streq(const char *s1, const char *s2);
```
Porovnává dva řetězce a ignoruje přitom volitelný znak konce řádky.
Prototyp pro i2c metody probe() se změnil:
```
int (*probe)(struct i2c_client *client, 
             const struct i2c_device_id *id);
```
Nový argument id podporuje aliasing jmen i2c zařízení.

Jedna změna, která se neuskutečnila, byla změna výchozí velikosti jaderných zásobníků na 4k na architektuře x86. Je to stále žádaný dlouhodobý cíl, ale těžko říci, kdy budou mít vývojáři dostatek důvěry, aby tuto změnu provedli.

Rozhovor: Andrew Morton o vývoji jádra

link

Andrew Morton je jaderné komunitě velmi dobře znám, protože dělá spoustu různých věcí: spravuje strom -mm s patchi, které jsou možná na cestě do hlavní řady, reviduje spoustu patchů, přednáší o spolupráci s komunitou a obecně dělá další důležité a viditelné práce spojené s vývojem jádra. V tom, jak věci dělá, se ale dějí změny, takže jsme mu e-mailem položili pár otázek. Dlouze odpověděl o stromu -mm, o tom, co se mění s příchodem linux-next, o kvalitě jádra a o tom, co mohou lidé udělat, aby bylo jádro lepší.

Před lety se objevily velké obavy, že by Linus mohl vyhořet. Zdá se, že jemu se od té doby život zjednodušil; místo toho nyní jsou nyní slyšet obavy z toho, že by mohl vyhořet Andrew. Zdá se, že toho děláš spoustu; jak držíš tempo a jak dlouho můžeme očekávat, že ti to vydrží?

Dělám toho méně než dříve. Hlavně proto, že musím - nejde roky intenzivně dělat tu samou věc a zůstat příčetný.

Stále stíhám revize a začleňování, ale intervaly vydávání -mm jsou nyní příliš dlouhé.

Samozřejmě je spousta věcí, které bych měl dělat, ale nedělám.

Během let se moje povinnosti naštěstí zmenšily - více správců provozuje vlastní stromy a zavedení stromu linux-next (který spracuje Stephen Rothwell) hodně pomohlo.

Strom linux-next znamená, že 85 % kódu, který jsem redistribuoval pro vnější testování, nyní redistribuuje Stephen. Někdy v příštím měsíci nebo dvou bych se chtěl ponořit do svých skriptů a najít způsob, jak dostat dostatečně stabilní části -mm do linux-next a potom snad budu schopen přestat tvořit -mm vydání úplně.

Takže: pracovní vytížení mi klesá, ostatní přebírají práci.

Jak můžeme pomoci?

Řekl bych, že hlavní je revidování kódu. Dobře revidovat nový kód je poměrně specializovaná funkce. Lidé, kteří se specializují v oblasti, kde se mění nový kód, jsou nejlepší revidovatelé, ale bohužel musím pravidelně revidovat záležitosti někoho jiného já sám.

Za druhé: pomohlo by, kdyby měly patche od lidí méně chyb. Stále musím opravovat stupidně velké množství varování překladače a chyb při překladu a každé vydání -mm vyžaduje okolo tří nebo čtyř oddělených dělení půlením, abych vyplel špatné patche.

Za třetí: testovat, testovat, testovat.

Za čtvrté: je pitomé, jak často jsem ten, kdo nejvíce reaguje na hlášení o chybě. Typicky si čtu linux-kernel každých pár dní po dávkách o 1000 emailech a pokaždé narazím na několik hlášení o chybě, které jsou den až tři staré a nikdo s nimi nic neudělal! A někdy vím, že osoba odpovědná za tuto část jádra si hlášení přečetla. Grr.

Myslíš, že kvalita jádra klesá? Většina vývojářů se zdá být poměrně optimistická co se problémů s kvalitou týče. Pokud budeme předpokládat, že tu máme rozdílné názory, odkud si myslíš, že pochází? Jak je můžeme vyřešit?

Myslíval jsem si, že klesá a myslím si, že bych si mohl myslet, že klesá dál. Vidím příliš mnoho regresí, které nikdy neopravíme. Zjevně opravujeme chyby tak dobře, jako je přidáváme, ale je velmi těžké rozhodnout, jaký je celkový výsledek.

Když jsem venku, často slýchávám lidi, jejichž stroje jsme rozbili způsobem, o jakém jsem nikdy předtím neslyšel. Žádám je, aby poslali hlášení o chybě (a očekávám, že se s tím stejně nic neudělá), ale oni to většinou neudělají.

Takže nevím, kde jsme, a nevím, co dělat. Jediné, co mohu dělat, je podporovat testery v hlášení chyb a vytrvalém upozorňování na ně a dloubat prstem do žeber vývojářů, kteří s nimi mohou něco dělat.

Myslím si, že by bylo hezké mít jaderné vydání, které by pouze opravovalo chyby. Takové, které by bylo hlasitě propagováno a během kterého bychom každého povzbuzovali k posílání hlášení o chybě a nedělali nic jiného, než že bychom se snažili je opravit. Na tohle jsem nijak netlačil, ale bylo by zajímavé to jednou zkusit. Pokud by to bylo prospěšné, mohli bychom to někdy udělat znovu.

Nedávno bylo v jádře odhaleno několik bezpečnostních problémů. Je nějaká konkrétní snaha o předcházení a opravování bezpečnostních děr? Co si myslíš, že bychom měli dělat v této oblasti?

Lidé stále vyvíjejí statické ověřovače kódu a novou infrastrukturu pro čas běhu [runtime infrastructure], které mohou bezpečnostní díry odhalit.

Bezpečnostní díra ale není nic jiného než chyba - je to jenom určitý druh chyby, takže jedním způsobem, jak omezit jejich objevování, je psát méně chyb. Vizte výše. Více opatrného programování, více opatrného revidování atd.

A teď - existuje nějaký zvláštní vzorec, který by byl typický pro chybu bezpečnost ovlivňující? Takový, který by nám umožnil věnovat více zdrojů na předcházení tomuto typu chyby na úkor "běžných" chyb? No, možná. Kdyby si někdo sedl a prošel tu záplavu bezpečnostních chyb v jádře za posledních pět let a vytáhl z toho celkový obraz, jaké bezpečnost ovlivňující chyby běžně děláme, pak by tato informace možná mohla pomoci revidovatelům kódu při jejich snaze a také nástrojům pro ověřování kódu.

Tím chci říct, že naše "bezpečnostní díry" jsou většinou chyby ve starobylém a záludném starém kódu, hlavně v ovladačích, které nikdo nepoužívá a které nikdo dokonce ani nenahrává. Proto věřím, že měřítka a měření bezpečnostních děr v jádře jsou zavádějící a zbytečná.

Bezpečnostní chyby, které jsou ve vnitřním jádře [core kernel] a které ovlivňují všechny uživatele, jsou vzácné - jednoduše protože na vnitřní jádro je zaměřeno hodně pozornosti a práce. To je důvod, proč byla nedávná chyba ve splice takové překvapení a taková rána.

Měl jsem pocit, že existuje určitý zmatek ohledně rozdílů mezi -mm a linux-next. Jak bys popsal účel těchto dvou stromů? A který z nich by měli zájemci testovat?

V současnosti se věci hodně mění.

Strom -mm se dřív skládal z následujícího:

Přibližně 80 stromů správců subsystémů (gitových i quiltových), např.: scsi, usb, net.
Různé patche, které jsem sesbíral a které by měly být ve stromech správců subsystémů, ale které do nich z různých důvodů nebyly začleněny. Spoustu času trávím jako záloha pro prosakující správce.
Patche, které jsou tvořeny v -mm stromě. Ty jsou nyní také organizovány jako subsystémy a napočítal jsem okolo 100 takových subsystémů, které jsou tvořeny v -mm. Například: fbdev, signals, uml, procfs. A správa paměti.
Spekulativnější věci, které nejsou krátkodobě určené k začlenění do hlavní řady, jako jsou nové souborové systémy (např. resier4).
Ladící patche, které nemám v úmyslu dostat do upstreamu.

Těch přibližně 80 subsystémových stromů má ve skutečnosti 85% podíl na změnách, které se dostanou do Linuxu. Téměř všechno ze zbývajících 15 % jsou patche, které zůstávají pouze v -mm.

Právě teď (v 2.6.26-rc4 "jaderného času") je těch přibližně 80 subsystémových stromů v linux-next. Nyní do -mm začleňuji linux-next místo 80 různých oddělených stromů.

Jak jsem zmínil dříve, plánuji přesunout do linux-next více z -mm - těch přibližně 100 malých subsystémových stromů.

Jakmile se tak stane, v -mm toho ve skutečnosti moc nezbude. Jenom:

Patche, které prosákly od správců subsystémů. Ty těmto správcům pošlu.
Spekulativní vlastnosti, které nejsou určeny pro další vydání.
Ladící patche, které nejsou určeny pro začlenění.

Máš nějaké specifické cíle pro vývoj jádra na další roky? Jaké to jsou?

Prostě držet kurz.

Stále doufám, že se vývoj jádra zpomalí. Nemůže existovat nekonečné množství nových vlastností! Nakonec bychom měli přejít do více udržujícího režimu, kde budeme jenom opravovat chyby, ladit výkonnost a přidávat nové ovladače. Slavná poslední slova.

A je trochu možné, že to se začíná dít právě teď. Mám pocit, že přichází méně "velkých" změn. Když jsem Linusovi poslal do 2.6.26 svůj obvyklý tisícipatchový proud, dostal jsem od něj email, kde se ptal (parafrázováno) "hele, kde jsou všechny ty děsivé věci?"

V diskuzích z počátku května Linus několikrát řekl, že si nemyslí, že by revidování kódu nějak pomáhalo. Souhlasíš s tímto názorem?

Ne.

Jak bys popsal skutečnou roli revidování kódu ve vývojovém procesu jádra?

Nachází chyby. Zlepšuje kvalitu kódu. Občas zabrání hodně hodně ošklivým věcem dostat se do výsledku. Takovým, jako díry umožňující získání roota [rootholes] ve vnitřním jádře. Slušné množství takových chyb jsem při revidování odhalil.

Také to zvětšuje počet lidí, kteří novému kódu rozumí - jak revidovatel(é), tak ti, kdo blíže sledovali revidování, jsou potom lépe schopni daný kód podporovat.

Také očekávám, že vidina toho, že jejich kód bude podrobně revidován, drží autory na nohou - nutí je lépe se o svoji práci starat.

Mezi tebou a Linusem musí probíhat docela živá komunikace, ale většina z ní, zdá se, není veřejná. Mohl bys popsat, jak vy dva spolupracujete? Jak jsou dělána rozhodnutí (jako například, kdy vydat)?

Ve skutečnosti si toho moc neřekneme. Jednou nebo dvakrát za rok se potkáme tváří v tvář a "ahoj, jak se máš".

Oba dva víme, jak ten druhý pracuje, a pro oba je ten druhý předvídatelný, takže s žádnými konkrétními akcemi toho druhého problémy nemáme. Ve skutečnosti se prostě nezdá, že by bylo potřeba říkat toho hodně.

Je něco dalšího, co bys chtěl vzkázat čtenářům LWN?

Jistě. Prosím, přispívejte do Linuxu. Skvělý způsobem, jak to dělat, je testovat nejnovější verzi z hlavní řady nebo linux-next nebo -mm a hlásit všechny problémy, na které narazíte.

Není potřeba nic zvláštního - jenom je nainstalujte na tolik strojů, na kolik si troufnete, a používejte je ke svým obvyklým denním aktivitám.

Jestli narazíte na chybu (a to narazíte), buďte prosím vytrvalí a nuťte nás ji opravit. Nenechávejte nás vydat jádro, které obsahuje vaši chybu! Křičte na nás, pokud to bude nutné. Jen nás nenechte rozbít vaše stroje.

Naši testeři jsou naším největším zdrojem - celý projekt jádra by se zadrhl a zastavil, kdyby jich nebylo. Proto jim hojně děkuji při každé příležitosti, kterou mám :).

Rádi bychom Andrewovi poděkovali za čas, který věnoval zodpovězení našich otázek.