Jaderné noviny – 12. 6. 2014: Co bude v Linuxu 3.16

1. 7. 2014 | Luboš Doležel | Jaderné noviny | 3966×

Aktuální verze jádra: 3.15. Citáty týdne: Dave Chinner, Peter Zijlstra. Začleňovací okno 3.16, část druhá.

Obsah

• Aktuální verze jádra: 3.15
• Citáty týdne: Dave Chinner, Peter Zijlstra
• Začleňovací okno 3.16, část druhá

Aktuální verze jádra: 3.15

Vyšlo jádro 3.15, a to 8. června. Mezi hlavní změny v této verzi patří výrazná vylepšení ve správě paměti, systémové volání renameat2(), POSIXové zámky specifické pro soubor, nový cíl mapovače zařízení nazvaný dm-era nebo rychlejší probouzení z uspání.

Začleňovací okno 3.16 zatím zůstává otevřené; přehled toho, co bylo začleněno, najdete níže. Linus poznamenal, že i když překryv začleňovacího okna 3.16 se stabilizací 3.15 zafungoval dobře, neznamená to, že je nakloněn tomu dělat to takto pokaždé. Navíc si nemyslím, že by to byl takový užasný zážitek, abych chtěl dělat podobný překryv pokaždé, pokud by pro to nebyl dobrý důvod. Bylo to fajn být během posledního týdne nebo rc produktivní (obvykle je to docela nuda), ale myslím si, že by to jen odvádělo pozornost v době, kdy si lidé mají dělat obavy o stabilitu rc.

Stabilní aktualizace: verze 3.14.6, 3.10.42 a 3.4.92 vyšly 7. června, následně pak 11. června vyšly verze 3.14.7, 3.10.43 a 3.4.93.

Citáty týdne: Dave Chinner, Peter Zijlstra

Neděláme tu vědecký výzkumný projekt. Pracujeme tu na opravdu velkém projektu v oblasti softwarového *inženýrství*.

Nebylo by tedy lepší používat procesy ze softwarového inženýrství namísto akademického peer review jako vzor pro náš proces revidování kódu?

-- Dave Chinner

Proto tedy budeš (nebo možná bude muset Intel obecně) opravdu explicitně popisovat, jak věci fungují a neskrývat to někde v ovladači a čarovat tam. To samé ostatně platí i pro jiné výrobce.

Pokud vy (výrobci [...]) nebudete hrát podle pravidel (a nebudete explicitně a viditelně popisovat, jak váš hardware funguje), pak zkrátka nebudete mít energeticky efektivní plánovač tečka.

Není tu žádný roh, za kterým byste se mohli skrývat, ani žádné magické závoje. Prostě to buď popíšete _veřejně_, nebo budete mít smůlu.

-- Peter Zijlstra

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

Toto je druhý díl seriálu, který popisuje začleňovací okno 3.16. Pokud vás zajímá, co se odehrálo během několika prvních dnů, pak se podívejte na článek z minulého týdne. Od té doby se Linus vrátil do větve master, respektive se tak stalo poté, co začlenil nějakých 6800 commitů ze své větve next. Nyní bylo do 3.16 začleněno 8179 patchů, což je 2831 od článku z minulého týdne.

Následuje přehled významných změn viditelných uživatelům.

• Migrace velkých stránek byla vypnuta na všech architekturách vyjma x86_64, jelikož je testována jen na této architektuře a na jiných se vyskytují chyby. K zapnutí na jiných architekturách může dojít, jakmile na to budou připraveny.
• Automatické vyvažování NUMA bylo vypnuto pro 32bitové x86. Stávající 32bitové systémy NUMA nejsou kódem moc dobře podporovány a vývojáři si nemyslí, že by stálo za to věnovat tomu nezbytné úsilí.
• Jaderné paměťové řídící skupiny (kmemcfg) byly v dokumentaci a Kconfigu označeny jako nepoužitelné ve skutečném světě, proto JE NEVYBÍREJTE, leda byste chtěli dělat na jejich vývoji.
• 16bitové segmenty zásobníku byly na 64bitových jádrech pro x86 opět povoleny. Tato funkce byla zakázána kvůli úniku informací z vrchních 16 bitů ukazatele na zásobník, což bylo nyní opraveno. Uživatelé tak opět mohou spouštět 16bitové programy pro Windows pod Wine na 64bitových jádrech.
• Jaderný kód pro EFI nyní zvládá znaky Unicode. Byl také upraven tak, aby ukládal a obnovoval registry související s čísly s plovoucí desetinnou čárkou okolo volání EFI, jelikož firmware EFI může používat FPU.
• Architektura ARM má podporu hibernace. Navíc teď na ní funguje Ftrace nad textem jen ke čtení v modulech. K tomu byla na této architektuře zlepšena podpora pro stack trace (výpis volání na zásobníku) díky odstranění funkcí pro výpis volání z výpisu volání a umožnění toho, aby kprobes zaznamenávaly výpisy volání.
• Systémové volání remap_file_pages() bylo označeno za zastaralé. Jeho náhrada, která bude jeho chování emulovat, ale bude pomalejší, zatím nebyla zaslána ke začlenění.
• Podpora hierarchie řídících skupin (cgroups) byla přepracována tak, aby byla nabízena jediná sjednocená hierarchie. Její používání je řízeno volbou při připojení __DEVEL__sane_behavior. Více na toto téma čtěte v dokumentaci.
• Patche Neila Browna zajišťující spolehlivé připojování NFS přes loopback byly začleněny přes strom NFS. Ostatní části jeho oprav byly začleněny přes jiné stromy.
• Zacházení s vnějším vyjádřením dat (XDR) v NFS bylo přepracováno tak, aby zvládalo ACL větší než 4 KB. Navíc vrací výsledky v readdir() v blocích větších než 4 KB, což vede k vyššímu výkonu u velkých adresářů.
• 64bitové little-endian PowerPC jádro nyní podporuje ABI ELFv2. Navíc přibylo nové 64bitové little-endian bootovací obalení pro PowerPC.
• Podpora nového hardwaru.

Vývojáři si mohou všimnout těchto změn:

• Parsování plochého stromu zařízení (FDT) bylo převedeno na používání libfdt. Znalost vnitřního fungování FDT byla odstraněna z většiny architektur až na PowerPC.
• Videobuf2 nyní podporuje standard DVB.
• Výhradně 32bitové setup_sched_clock() bylo odstraněno. Volání této funkce byla převedena na sched_clock_register().
• Rozhraní create_irq() a destroy_irq() (a jeho varianty) pro ošetřování nesouvislé (sparse) alokace IRQ bylo odstraněno. Thomas Gleixner to popsal takto: zbavujeme se děsivého rozhraní create_irq spolu s jeho ještě strašnějšími variantami.
• Podpora ARM level 2 cache byla pročištěna, což vede k mnohem hezčí struktuře a jistým vylepšením ve výkonu, jak říká Russell King ve své žádosti o přetažení.
• Na ARM64 (aarch64) přibyly optimalizace pro rutiny pro práci s pamětí a řetězci, stejně tak i pro kryptografické algoritmy (rodina SHA, AES a GHASH). Navíc přibyla podpora Ftrace.
• Některé trasovače (latency, wakeup, wakeup_rt, irqsoff, preemptoff, preemptirqsoff) lze nyní používat v oddělených trasovacích instancích, ačkoliv lze v jeden okamžik používat jen jednu instanci každého z trasovačů. Navíc jde používat trasovače funkcí a grafů funkcí dohromady.
• Jako součást opravy pro CVE-2014-4014 byla funkce inode_capable() přejmenována na capable_wrt_inode_uidgid(), aby název lépe odpovídal tomu, co funkce dělá.
• Byl přidán skript decode_stacktrace.sh, který převádí offsety ze symbolů na názvy souborů a čísla řádek pro snazší čitenost.

V tento moment bychom už měli být u konce začleňovacího okna, i když se během následujících dnů ještě může objevit několik zajímavých patchů. Těšte se na závěr v příštím vydání JN.

       

Komentáře

[pavlix]

Nebylo by tedy lepší používat procesy ze softwarového inženýrství namísto akademického peer review jako vzor pro náš proces revidování kódu?

Jenom to ne :D.

[Petr Tomášek]

Nebylo by tedy lepší používat procesy ze softwarového inženýrství namísto akademického peer review jako vzor pro náš proces revidování kódu?

Jasně příjde nějaký korporátnický manažér a svoboda bude fpiči... :-/

[Michal Kubeček]

Občas neškodí podívat se na kontext, než začnete bít na poplach. Konkrétně šlo o tohle:

IMO, every reviewer has their own developement environment and they should be at least testing that the change they are reviewing doesn't cause problems in that environment, just like they do for their own code before they post it for review.

Let me ask you this. In the scientific community, when someone posts a research project and asks their peers to review their work. Are all those reviewers required to test out that paper? Or are they to review it, check the math, look for cases that are missed, see common errors, and other checks? I'm sure some reviewers may do various tests, but others will just check the logic. I'm having a very hard time seeing where Reviewed-by means tested-by. I see those as two completely different tags.

We are not conducting a scientific research experiment here. We are conduting a very large software engineering project here.

So perhaps we should be using robust software engineering processes rather than academic peer review as the model for our code review process?

Nepopírám, že ta myšlenka je kontroverzní a že za otestování na zjevné regrese by měl být v první řadě zodpovědný autor patche, ale ať to čtu, jak to čtu, nějak v tom ne a ne vidět to omezování svobody ze strany korporátnického manažera.

[Petr Tomášek]

Nepopírám, že ta myšlenka je kontroverzní a že za otestování na zjevné regrese by měl být v první řadě zodpovědný autor patche, ale ať to čtu, jak to čtu, nějak v tom ne a ne vidět to omezování svobody ze strany korporátnického manažera.

Však to přijde, až přijdou ty tzv. „robust software engineering processes“...

[koudy]

Mě to přijde jako docela samozřejmost, otestovat si program který píšu (v tom se asi se mnou nebude přít nikdo, kromě nadřízených/prodejců :D ) a nebo po někom kód kontroluju. (tady je to závislé případ od případu)

 

Chápu, že patch pro nějaký hack pro síťování s ARM procesorem, si každý doma na své x86 neozkouší.

Na druhou stranu bych čekal, že když už děláte "Reviewed-by:", tak vlastníte železo, na kterém to zkoušíte.

[Michal Kubeček]

Už takhle je mi záhadou, jak někteří maintaineři zvládají ten provoz. Pokud by měli ještě navíc pro každý patch provádět nějakou sadu základních regresních testů (jak navrhuje Dave Chinner), znamenalo by to enormní nárůst práce. Vaše představa, že by měli testovat funkčnost každého patche, je zcela mimo realitu.

[koudy]

Měl jsem na mysli spíš jednou za x dní si sesumírovat všechny patche a otestovat to jako celek.

Možnost, že by se to mělo dělat hned po přietí patche a hned to zkoušet, mi ani nepřišla na mysl. Bylo by to totiž ŠÍLENÝ něco takovýho chtít po vývojářích :)

Na druhou stranu, by jistě šlo velké množství těchto testů zautomatizovat a provádět je například po zkompilování jádra (třeba "make zImage_test" - což by spustilo virtuální PC..., ne dobře to je příliš velké sci-fi, ale asi chápete kam tím mířím)

[David Heidelberg]

Na druhou stranu bych čekal, že když už děláte "Reviewed-by:", tak vlastníte železo, na kterém to zkoušíte.

Reviewed-by nemá s testováním nic společného. Znamená to, že sis kód přečetl a připadá Ti v pořádku. Samozřejmě se předpokládá dostatečná znalost kontextu.

Naproti tomu Tested-by znamená, že nemusíš rozumět kódu, ale že si to ozkoušel a funguje to.