Jaderné noviny – přehled za červenec 2019

5. 8. 2019 | David Kolibáč | Jaderné noviny | 2373×

Přehled červencových vydání Jaderných novin: stav vydání jádra, citáty týdne a seznam článků týkajících se jádra.

Vydání z 4. 7. 2019

LWN.net Weekly Edition for July 4, 2019.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 3. července 2019

Vývojové jádro 5.2-rc7 bylo vydáno 30. června. Linus řekl: „Všechno je to malé a celkem nezajímavé. Aktualizace architektur, sítě, základy jádra, souborové systémy, různé ovladače. Nic nevyčuhuje – přečtěte si přiložený stručný seznam.“

Stabilní aktualizace: 4.14.131, 4.9.184 a 4.4.184 byly vydány 27. června; obsahují jediný patch, který cílí na regresi způsobenou opravami pádu TCP SACK. 5.1.16, 4.19.57 a 4.14.132 byly vydány 3. července.

Citáty týdne

Quotes of the week. Jonathan Corbet. 3. července 2019

Sdílený kód je dobrý, dokud se sdílení nestane tak složitým, že ani lidé schopní kód změnit nejsou ochotni na něj sáhnout a opravit ho. To se stalo bufferhead a opakuje se to napříč kódem jaderné infrastruktury.

—Dave Chinner

Stojím si za vyjádřením, že kdokoliv tvrdí, že chce stabilní API pro ovladače, po technické stránce neví, co dělá. Množství balastu, které se v průběhu let a desetiletí nahromadí v interních API, operační systém zabije a máme dřívější příklady, kdy se tak stalo.

—Greg Kroah-Hartman

Jménem Linux Foundation Technical Advisory Board (TAB) bych ráda oznámila, že upravujeme pravidla hlasování pro letošní volby do TAB. Jednořádkové shrnutí zní tak, že bychom rádi přešli na elektronické volby namísto papírových hlasovacích lístků, aby se mohlo zúčastnit více členů komunity a ovlivnit složení TAB.

—Laura Abbott

Články

• Poskytování širší dostupnosti bpf(): kontroverzní postup k uvolnění přístupu k systémovému volání bpf().
• TurboSched: návrat sdružování drobných úloh: změny plánovače, aby se lépe využíval režim „turbo“ CPU.

---

Vydání z 11. 7. 2019

LWN.net Weekly Edition for July 11, 2019.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 10. července 2019

Jádro 5.2 bylo vydáno 7. července. Linus Torvalds řekl: „Navzdory docela pozdnímu vrácení zásadního kódu nevidím žádný skutečný důvod, proč věnovat další týden rc, takže 5.2 vychází normálně podle plánu.“

Mezi významnějšími změnami v 5.2 jsou nový příznak CLONE_PIDFD volání clone() za účelem získání pidfd pro nový proces, výrazné zlepšení výkonu verifikátoru BPF, které umožňuje navýšit horní limit velikosti programů BPF na 1 milion instrukcí, háček BPF pro správu nastavení sysctl, skupinu nových systémových volání pro připojování souborových systémů, vyhledávání nezávislé na velikosti písmen v souborovém systému ext4, zmrazování procesů pro druhou verzi řídících skupin, sledování zátěže a samozřejmě nepočítaně oprav. Více podrobností na stránce KernelNewbies o vydání 5.2.

Stabilní aktualizace: 5.1.17, 4.19.58, 4.14.133, 4.9.185 a 4.4.185 byly vydány 10. července.

Rjabicev: Patche vryté do vývojářských podpisů

Ryabitsev: Patches carved into developer sigchains. Jonathan Corbet. 8. července 2019

Konstantin Rjabicev zveřejnil dlouhý blogový zápisek popisující jeho představu o opuštění e-mailu pro účely vývoje jádra. „Myslím, že je příliš pozdě na to přijít s řešením, které by poskytovalo decentralizovanou, samoarchivující, plně ověřitelnou, všepokrývající vývojovou platformu řešící všechny aspekty vývoje jádra, nejen kód. Musí nás odtrhnout od e-mailových konferencí, ale aniž by v ní figuroval centrální bod důvěry, autority nebo selhání.“

Citát týdne

Quote of the week. Jonathan Corbet. 10. července 2019

Myslím, že slova „stabilní jádro“ čteme odlišně. Ty vidíš „stabilní jádro“ jako jádro, které zůstává více méně pořád stejné a přijímá jen několik málo kritických oprav.

Na druhé straně je moje očekávání od „stabilního jádra“ takové jádro, které neobsahuje známé chyby. Slovo „stabilní“ si spojuji se stabilním běhovým prostředím, spíš než stabilním kódem.

—Sasha Levin

Články

• Měkká afinita CPU: návrh flexibilnější politiky přiřazování procesů CPU.
• clone3(), fchmodat4(), a fsinfo(): trojice nových systémových volání pro Linux.
• ION opouští staging: další část jaderné infrastruktury Androidu míří do hlavní větve jádra.
• Třetí summit o správě napájení řízené operačním systémem: první skupina příspěvků z konference OSPM 2019.
  • Mezi dvěma ohni: jak těžké je spravovat nečinné CPU.
  • Plánování virtuálních strojů a plánování ve virtuálních strojích.
  • I-MECH: realtime virtualizace pro průmyslovou automatizaci.
  • Cesta k probuzení CFS a Arm big.LITTLE/DynamIQ.
  • Testování chování plánovače.
  • Budoucnost SCHED_DEADLINE a SCHED_RT na systémech s omezenou či asymetrickou kapacitou.

---

Vydání z 18. 7. 2019

LWN.net Weekly Edition for July 18, 2019.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 16. července 2019

Začleňovací okno 5.3 bylo otevřené, uzavření bylo očekáváno 21. července. Přehled, co bylo zpočátku začleněno.

Stabilní aktualizace: 5.2.1, 5.1.18 a 4.19.59 byly vydány 14. července.

Citát týdne

Quote of the week. Jonathan Corbet. 17. července 2019

Zbývající změny, které jsou potřeba, aby [realtime preempce] byla prvotřídně podporována v hlavní větvi jádra, už nejsou hlavní větvi hned prokazatelně prospěšné. Většina z nich spočívá buď v přeskládání toku kódu, nebo přidání funkcí speciálně pro RT. Ale teď to narazilo do zdi a zvrhlo se v klasický problém vejce a slepice:

Správci se oprávněně mají napozoru před těmito změnami, protože dávají smysl pouze v poslední fázi integrace RT do hlavní hlavní větve jádra.

Cílem přidání CONFIG_PREEMPT_RT je vyřešit to, má to být jasné znamení, že RT bude zcela integrováno do hlavní větve jádra.

—Thomas Gleixner

Články

• První polovina začleňovacího okna 5.3: pohled na to, co se do hlavní větve jádra první dostalo pro vydání 5.3.
• Bcachefs se blíží: nový souborový systém, který pochází z cachovací vrstvy bcache, vykročil směrem k hlavní větvi jádra.
• Kdo se bojí velkého, zlého optimalizujícího překladače: shrnutí potenciálních úskalí v překladačích pro vývojáře jádra a dalšího paralelního kódu.
• Třetí summit o správě napájení řízené operačním systémem: zbytek příspěvků z konference OSPM 2019.
  • Přepracování vyvažování zátěže CFS.
  • Neměnné škálování frekvence na x86_64.
  • Jak ještě můžeme zlepšit efektivitu schedutil?
  • Měkká afinita plánovače.
  • SCHED_DEADLINE na heterogenních vícejádrech.
  • TurboSched.
  • Nové přístupy ke správě teploty.
  • Proxy vykonávání.

---

Vydání ze 25. 7. 2019

LWN.net Weekly Edition for July 25, 2019.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 24. července 2019

Vývojové jádro 5.3-rc1 bylo vydáno 21. července. „Každopádně, navzdory počátečním úskalím a velikosti se věci koncem začleňovacího okna více méně srovnaly. A je toho hodně, co by se v 5.3 mohlo líbit.“

Stabilní aktualizace: 5.2.2, 5.1.19, 4.19.60, 4.14.134, 4.9.186 a 4.4.186 byly vydány 21. července.

Obrovské aktualizace 5.2.3, 5.1.20 a 4.19.61 byly plánovány na 26. července, kdy skutečně vyšly.

Cook: Bezpečnostní záležitosti v Linuxu 5.2

Cook: security things in Linux v5.2. Jake Edge. 18. července 2019

Kees Cook na svém blogu prochází změny týkající se bezpečnosti v Linuxu 5.2. „Ačkoliv seznamy volného místa alokátorů SLUB a SLAB byly již nějaký čas randomizovány, u nadřazeného alokátoru stránek tomu tak nebylo. Takže umístění v paměti všeho, co provádělo alokaci mimo kmem_cache/kmalloc(), bylo deterministické. To je špatně jednak pro zabezpečení, jednak pro některé případy správy mezipaměti. Dan Williams nyní implementoval i tuto randomizaci pod CONFIG_SHUFFLE_PAGE_ALLOCATOR, což do rozložení paměti přidává další prvek nejistoty, i když s jen poměrně nízkou granularitou 4 MB (viz SHUFFLE_ORDER). Také si všimněte, že tato funkce musí být povolena pomocí page_alloc.shuffle=1 při zavádění systému, pokud nemáte přímo mapovanou mezipaměť na straně paměti (zkontrolovat si to můžete v /sys/module/page_alloc/parameters/shuffle).“

Články

• Analýza jádra pomocí bpftrace: rozličné příklady, jak se s nástrojem bpftrace podívat do vnitřností jádra.
• Druhá polovina začleňovacího okna 5.3: zbytek změn ve vývojovém cyklu 5.3.
• Přístup k blokovým zařízením se zónami pomocí zonefs: speciální souborový systém pro úložná zařízení rozdělená do zón.

       

Komentáře

[xkucf03]

Stojím si za vyjádřením, že kdokoliv tvrdí, že chce stabilní API pro ovladače, po technické stránce neví, co dělá. Množství balastu, které se v průběhu let a desetiletí nahromadí v interních API, operační systém zabije a máme dřívější příklady, kdy se tak stalo.

Tak zrovna k tomuhle slouží sémantické verzování – tzn. zpětná kompatibilita se nemusí udržovat donekonečna¹, ale jen v rámci major verze. Pokud se mění jen minor a patch verze, tak by to mělo mít kompatibilní rozhraní.

_{[1] takže nehrozí, že by jádro bylo zaneřáděné nějakými historickými a nepoužívanými API}

[luky]

Jenze ted se API meni i v patch verzich, kdyz je to nutne pro opravu chyb. Jak by se podle tebe takove chyby resily? Mne prijde lepsi rozbit externi ovladac, nez nechat v jadre diru.

[xkucf03]

API = rozhraní. Je skutečně nutné ho měnit kvůli opravě chyby? Pokud ano, tak je to chyba návrhu a chtělo by to k němu příště přistupovat zodpovědněji. Někdy k tomu může dojít, ale měla by to být výjimečná situace. Může se např. stát, že někdo s tou chybou počítá – a pak je vlastně oprava chyby zpětně nekompatibilní změna.

A hlavně ten argument, na který jsem reagoval, byl:

Množství balastu, které se v průběhu let a desetiletí nahromadí v interních API, operační systém zabije

Tzn. obava o to, že by se v Jádře hromadil starý kód resp. stará rozhraní, která reálně už nikdo nepoužívá. To je ale zbytečná obava, protože tato rozhraní lze vyházet při povýšení major verze. Tzn. třeba jednou za rok za dva nebo jiné dohodnuté období se udělá čistka a zahodí se zastaralá rozhraní – ale všechny verze mezi tím budou zpětně kompatibilní.

Jsou dva extrémní přístupy: a) dodržovat zpětnou kompatibilitu navždy a b) neřešit ji a dělat nekompatibilní změny kdykoli. A pak je tu to sémantické verzování, které nekompatibilní změny nezakazuje (takže lze kód/rozhraní čistit), ale dělá tyto změny řízeně a předvídatelně.

Chápu, že Linux je trochu specifický projekt v tom, že tam je snaha mít všechen kód v jednom gitu a spravovaný centrálně (byť mnoha různými přispěvateli) a udržovat si nějaké moduly bokem není úplně běžné, ale i tak si myslím, že není nutné na tu kompatibilitu takhle úplně rezignovat.

[luky]

Tvoje predstava je mimo realitu vyvojoveho cyklu kernelu. Stabilni minor verze kernelu se udrzuje treba v Redhatu pres 10 let. EOL na RHEL6 je nekdy v 2020 a ma kernel 2.6.32 z 2009 (EOL te verze v upstreamu byl 2016, takze zila pres 7 let). Nikdo nechce udrzovat nejake rozhrani 10 let, kdyz ani nevi, jestli ho vubec nekdo mimo oficialni strom pouziva.

Udrzujeme +-500000 radek jaderneho kodu a cas potrebny na rebase kernelu na vyssi patch level je zanedbatelny (trva mi to vetsinou mene nez 1MD), zejmena kdyz vetsina zmen v rozhrani je z duvodu opravy chyb a tudiz bychom kod museli stejne menit. Changelog pri updatu kernelu musis cist tak jako tak.

Vzhledem k tomu, ze rozhrani jadra je rozsahle, musel bys semanticky verzovat jednotlive soubory pripadne subsystemy, protoze jinak bys musel zmeny bud odkladat a nebo casto zmenit major verzi jadra, takze minor a patch cislo by bylo k nicemu. Predstava, ze kopa semantickej cisel by tu praci ulehcila, je naivni.

[xkucf03]

Stabilni minor verze kernelu se udrzuje treba v Redhatu pres 10 let … Nikdo nechce udrzovat nejake rozhrani 10 let, kdyz ani nevi, jestli ho vubec nekdo mimo oficialni strom pouziva.

Lidé obvykle používají stabilní verze softwaru proto, aby měli jistotu, že se v nich nebude nic měnit, že se budou jen opravovat chyby a že se jim při těchto aktualizacích nerozbije nic, co dříve fungovalo. Pokud z toho budeš nějaké API vyřazovat, protože „se ti ho nechce udržovat“, tak už tam jaksi chybí ta žádoucí vlastnost, že po aktualizaci bude fungovat vše, co fungovalo dřív, a popírá to smysl té stabilní verze, ne?

[luky]

Lidé obvykle používají stabilní verze softwaru proto, aby měli jistotu, že se v nich nebude nic měnit, že se budou jen opravovat chyby a že se jim při těchto aktualizacích nerozbije nic, co dříve fungovalo. Pokud z toho budeš nějaké API vyřazovat, protože „se ti ho nechce udržovat“, tak už tam jaksi chybí ta žádoucí vlastnost, že po aktualizaci bude fungovat vše, co fungovalo dřív, a popírá to smysl té stabilní verze, ne?

Vubec ne, protoze ten, kdo tem lidem dodava jadro jim patricne upravi i ostatni casti, tak aby byly kompatibilni. Pokud nejaka distribuce aktualizuje jadro a ta zmena vyzaduje patch mimojadernych modulu, dojde k aktualizaci a prekompilovani modulu behem updatu. Naproste minimum lidi si udrzuje vlastni jaderne moduly a proto od stabilni verze jadra ocekavaji minimalni zmeny v chovani (napriklad zmeny logiky planovace) a ne stabilni API.