Jaderné noviny – 23. 1. 2014: Co bude v Linuxu 3.14

10. 2. 2014 | Luboš Doležel

Články - Jaderné noviny – 23. 1. 2014: Co bude v Linuxu 3.14  

Aktuální verze jádra: 3.13. Citáty týdne: Ted Ts'o, Linus Torvalds. Kroah-Hartman: Podrobnosti o kdbusu. Začleňovací okno 3.14, část první.

Obsah

• Aktuální verze jádra: 3.13
• Citáty týdne: Ted Ts'o, Linus Torvalds
• Kroah-Hartman: Podrobnosti o kdbusu
• Začleňovací okno 3.14, část první

Aktuální verze jádra: 3.13

Vyšlo jádro 3.13, a to dne 19. ledna. Kvůli cestování se vydání opozdilo o týden, ale řekl bych, že to nevadí. Přišlo několik oprav navíc a i když to nebylo mnoho, tak je to jen dobře. Mezi hlavní novinky ve verzi 3.13 patří podpora filtrovacího enginu nftables, řada vylepšení v plánovači NUMA, práce na blokové vrstvě s vícero frontami, podpora přepínače pro ARM big.LITTLE a ještě více; podrobnosti najdete na příslušné stránce na KernelNewbies.

Stabilní aktualizace: během uplynulého týdne žádné nevyšly a ani se žádné nerevidují.

Citáty týdne: Ted Ts'o, Linus Torvalds

Nevím, jestli se dá RNG lépe popsat jako „stánek s dobrotami“ nebo „káva na osvěžení“, jako se píše v Parkinsonově třetí kapitole „Těžké prachy nebo Bod vadnoucího zájmu“, ale jedno vím jistě. Nejde o reaktor za miliardy.

-- Ted Ts'o (stojí za to přečíst si celé)

Tak či tak bych ti doporučil omezit chobotnicové slučování (octopus merge) na ~15 rodičů nebo méně, aby se z toho vizualizační nástroje nezbláznily. Ve většině případů se možná snaž o 10.

Je to přetažené a je to v pořádku, ale je nutné hlídat si hranici mezi „chobotnicové slučování je v pohodě“ a „proboha, to není chobotnice, to je slučování Cthulhu“.

-- Linus Torvalds

Kroah-Hartman: Podrobnosti o kdbusu

Tak trochu v návaznosti na popis přenášky o kdbusu (z linux.conf.au) v minulém vydání Jaderných novin napsal Greg Kroah-Hartman blogový zápisek, který se kdbusem zabývá trochu více do hloubky. Zejména vysvětluje, proč kdbus v dohledné době nenahradí IPC mechanismus binder na Androidu – pokud vůbec tedy. Model binderu je velmi omezený, ve svém použití neohebný, ale velmi mocný a s extrémně malou režií a velkou rychlostí. Binder zajišťuje, že ten samý časový úsek CPU přejde z volajícího procesu do vlákna volaného procesu a pak zase zpátky, jakmile bude volání hotové. Nedochází k téměř žádnému plánování a velmi se podobá systémovému volání v jádře, které se postará o všechnu práci za volající proces. Toto rozhraní je ušité na míru levným zařízením s malým množstvím RAM a slabým výkonem CPU.

Začleňovací okno 3.14, část první

Začleňovací okno pro jádro 3.14 se otevřelo 20. ledna. V době psaní tohoto textu bylo přetaženo už něco přes 3300 neslučovacích sad změn, včetně významných novinek. Mezi ty viditelné uživatelům patří:

• Byl začleněn patch pro lockdep v uživatelském prostoru. Toto zpřístupňuje jadernou výbavu pro ladění zámku aplikacím v uživatelském prostoru.
• Po létech vývoje byla konečně začleněna třída plánovače deadline. Tato třída umožňuje procesům stanovit objem práce, který je potřeba udělat, a termín, kdy to má být hotové; při troše snahy pak může zaručit, že všechny procesy své termíny splní. Pro více informací o aktuálním stavu plánovače deadline vizte tento rozpracovaný dokument.
• Architektura m68k má podporu pro systémové volání kexec().
• Xen už není na architektuře ia64 podporován.
• Architektura arm64 má podporu pro návěští skoků [jump labels] a alokátor paměti CMA.
• Subsystém událostí perf získal podporu pro intelovské čítače spotřeby energie „RAPL“. Nástroj perf pro uživatelský prostor rovněž obdržel dlouhý seznam nových funkcí a vylepšení; podrobný seznam najdete v žádosti o přetažení Inga Molnara.
• Byly začleněny patche pro náhodné rozvržení adresního prostoru jádra. V závislosti na tom, komu věříte, může tato funkce učinit jádro odolnějším proti určitým druhům útoků. Pozor na to, že povolení této funkce rozbije hibernaci a události perf.
• Podpora nového hardwaru (například platforem Intel Clovertrail a Merrifield).

Mezi změny viditelné vývojářům jádra patří:

• Byly přidány nové operace smp_load_acquire() a smp_store_release() pro práci s paměťovými bariérami; pro více informací o tom, proč jsou třeba a k čemu slouží, čtěte tento článek.
• Jádro je možné sestavit s volbou kompilátoru -fstack-protector-strong, která je dostupná v GCC od verze 4.9. Tato volba umožňuje, aby více funkcí v jádře používalo ochranu proti přepisu zásobníku a režie přitom byla (doufejme) stále přijatelná.
• preempt_enable_no_resched() už není dostupné modulům, které by podle vývojářů plánovače neměly být kreativní při preempci.
• Vnitřnosti virtuálního systému souborů sysfs jsou masivně přepracovávány, aby vznikl nový systém souborů „kernfs“, jenž bude sloužit jako základ řady takových systémů souborů. Prvním cílem je systém souborů pro řídící skupiny, ale možná dojde i na další. Tato práce není v 3.14 hotová, ale i tak došlo k řadě vnitřních změn.
• Nová dokumentace v Documentation/driver-model/design-patterns.txt se snaží formalizovat některé návrhové vzory, které jsou k vidění v kódu ovladačů. Je to teprve první verze; rozšíření by nepochybně byla vítána.
• Objevila se nová infrastruktura „komponentizovaných subsystémů“ pro správu složitých zařízení složených z více menších, interaktivních zařízení; více najdete v commitu.
• Paměťový alokátor Android ION byl začneněn do stromu staging. Byla začleněna i řada vylepšení včetně změn v IONu, aby používal rozhraní dma-buf a alokátor CMA.

Pokud bude cyklus probíhat jako obvykle, pak bude okno otevřené přibližně do 2. února. Zatím ještě nebyla přetažena řada stromů – například síťová – takže lze očekávat ještě nemalé množství změn. Příště se opět dozvíte více.

Diskuse k tomuto článku

[Pev]

náhodné rozvržený adresního prostoru jádra ?

Díky za překlad.

[Luboš Doležel (Doli)]

Díky, opraveno.

[Petr Ježek]

Filozofie vývojářů Binderu by měla být i u Linuxu. Proč? Protože více malých věcí, které to dělají dobře a rychle v souhrnu znamená lepší variantu než jedna věc, která to vše dělá pomalu a do vyladění problematicky. O nákladech vývoje nemluvě...

[clayman]

Nejsem si jist, že s tímto postojem souhlasím. Jsem pro to, používat na míru šité implementace, pokud přesně znám prostředí, kde bude daný kus software běžet, ale co když budu potřebovat mírně poupravit chování nějakého takového existujícího řešení? Zkopírováním a úpravou? To potom skončím s dvaceti implementacemi, které všechny dělají rámcově to samé, ale každá trochu jinak.

[j]

Ono je lepsi mit na to jednoho stovky MB velkyho molocha, s miliardou konfiguracnich voleb, o kterych stejne nikdo nevi co vlastne poradne delaj ...

[clayman]

Já jsem něco takového tvrdil? Řekl jsem a stojím si za tím, že pro Android je možná výhodnější mít na míru ušité řešení vzhledem k omezením vyplývajícím z hardware, ale není to všespásný přístup.

[Josef Kufner]

Druhou možností je mít připravené komponenty a poskládat je podle aktuální potřeby do nové aplikace. Pak není ani moloch, ani obludná konfigurace.

[alkoholik]

"10 million pound nuclear reactor" bych hadal spis na "reaktor za 10 milionu liber".
Kilotuny jsou raze atomovych bomb, reaktory maji megawatty.

[Luboš Doležel (Doli)]

To zní rozumně.

[alkoholik]

A odkaz mi dava za pravdu..
..approve the ten million pounds budget for building an atomic reactor..

[Zbyněk]

Mohli by dát kódové jméno Pí, když už jsme dospěli k číslu 3.14

[lertimir]

Číslování linuxového nedělá Knuth. To by pak bylo 3.14->3.141->3.1415.

[D.A.Tiger]

No zápis čísla PI je velký na dostatečné množství opravných vydání a patchů. Jen je otázkou, jestli by pak časem nezabralo celou plochu monitoru jen zobrazení aktuální verze systému...