Jaderné noviny - 28. 1. 2016: Začleňovací okno 4.5 (3. část)

3. 2. 2016 | Redakce | Jaderné noviny | 2350×

Stav vydání jádra. Citáty týdne. Začleňovací okno 4.5, 3. část.

Stav vydání jádra

Současný vývojový kernel 4.5-rc1 byl vydán 24. ledna. Začleňovací okno 4.5 je uzavřeno. Linus: „Docela normální vydání – ani velké, ani malé. I statistika vypadá celkem normálně, více než 70 % novinek připadá na ovladače (k největším patří gpu, sítě, zvuk, staging (testování), fbdev, ale už je po všem).“

Stabilní aktualizace:4.3.4, 4.1.16, 3.14.59 a 3.10.95 byly vydány 23. ledna. Verze 4.4.1, 4.3.5, 4.1.17, 3.14.60 a 3.10.96 byly v době psaní tohoto článku (minulý týden) v procesu revidování a nyní by již měly být dostupné. Greg Kroah-Hartman varuje: „Ještě stále je zde mnoho nezpracovaných patchů, konkrétně více než 400, takže některé vaše oblíbené patche ještě nemusí být součástí těchto vydání.“ Možná by tedy bylo lepší si počkat na stabilnější aktualizace.

Citáty týdne

Ale pokud bych příležitostně nepřidal takový text, mohli by tito lidé jednoduše přečíst většinu memory-barriers.txt a domnívat se, že jim vlastně rozumí. Takže občas jim tuhle domněnku musím podrazit.

-Paul McKenney

Řada projektů by považovala 400 patchů za velké vydání, ale tady je až za dvěma tečkami.

-Avi Kivity

Začleňovací okno 4.5 (část 3.)

Linus vypustil vývojový kernel 4.5-rc1 a uzavřel začleňovací okno pro tento cyklus 24. ledna, jak jsme očekávali. Od minulého týdne bylo začleněno téměř 2000 změn, mezi nimi některé opravdu významné:

• Nový nástroj UBSAN kontroluje běžící jádro, aby detekoval různé typy nedefinovaného chování, které mohou vést k nepříjemným chybám. Tento seznam změn vyjmenovává chyby, které se již díky nástroji UBSAN podařilo odhalit a opravit. Viz Documentation/ubsan.txt pro návod k použití.
• Ukázalo se, že nová volba CONFIG_IO_STRICT_DEVMEM, která blokuje přístup k paměti (skrze /dev/mem) zabrané ovladači zařízení, občas způsobuje problémy se zaváděním systému, takže je nyní ve výchozím stavu vypnutá.
• Práce, které mají sjednotit jádro pro ARM tak, aby jedno sestavení mohlo běžet na různých procesorech, dosáhly významného pokroku sloučením několika minoritních platforem:

  Jde o vyvrcholení pět let trvající snahy o sloučení platforem ARMv6 a ARMv7, která by umožnila jejich bootování na stejném kernelu. Jde o obrovskou spoustu práce zahrnující čištění kódu a refaktoring, podílelo se na ní mnoho lidí a v jejím rámci vzniklo několik nových (i důležitých) subsystémů, které umožnily lepší abstrakci nad detaily specifickými pro jednotlivé platformy.

• Subsystém pro souborové systémy v uživatelském prostoru (FUSE) získal podporu SEEK_HOLE a SEEK_DATA v systémovém volání lseek().
• Systémové volání epoll_ctl() podporuje nový příznak EPOLLEXCLUSIVE, který způsobí, že epoll_wait() jen vzbudí jeden proces, když je připravený deskriptor souboru. Viz tento článek.
• Mapování DirectAcces (DAX) nyní funguje ve spojení se systémovými voláními msync() a fsync() správně.
• Souborový systém ext4 získal podporu „projektových kvót“, kde mohou být rozptýlené soubory přiřazeny ke stejnému „projektu“ a je jim přidělena vlastní kvóta. Tato funkce žalostně postrádá dokumentaci, ale nějaké informace se dají najít v záhlaví tohoto patche.
• Implementace XFS příkazů XFS_IOC_FSSETXATTR a XFS_IOC_FSGETXATTR ioctl() byla přesunuta do úrovně virtuálního souborového systému a také byla přidána implementace pro souborový systém ext4. Tato operace, rovněž velmi nedostatečně zdokumentovaná, umožňuje zjišťovat (a nastavovat) různé atributy souborů, včetně neměnnosti, zda by zápisy měly být vždy synchronní, výjimky ze záloh a podobně. Viz horní části tohoto commitu pro seznam podporovaných atributů.
• Souborový systém Ceph nyní podporuje asynchronní I/O.
• Nově podporovaný hardware:
  • Systémy a procesory: Systémy Renesas R-Car H3, procesory Ralink MT7621, Microchip PIC32MZDA, systémy Socionext UniPhier a procesory Nvidia Tegra 132.
  • Různé: Ovladače Qualcomm pro „sdílenou paměť stavového automatu“, řadiče Qualcomm pro subsystém bezdrátového připojení, řadiče Qualcomm PCIe, interprocesory komunikačního subsystému TI AMx3 Wkup-M3, řadiče domén Raspberry Pi, duální časovače TI OMAP, hostitelské řadiče HiSilicon Hip06 a netransparentní bridge hardwaru pro sledování výkonu AMD.

Nakonec, v prosinci si Linus všiml, že nástroje pro přístup v uživatelském prostoru (get_user() a další), se na některých profilech objevovaly velmi často, zvláště na systémech s aktivním režimem supervizora pro omezení přístupu. Problém je v tom, že kernel často potřebuje vykonat několik přístupových sekvencí, a výsledkem je, že dochází k častému vypínání a zapínání prevence přístupu.

Řešením, jak už to tak bývá, je dávkování (batching): vypněte prevenci přístupu pouze jednou, udělejte, co je třeba, a znovu ji zapněte. Linus připravil pro tuhle možnost sadu maker:

   user_access_begin();
   unsafe_put_user(value, user_space_pointer);
   unsafe_get_user(value, user_space_pointer);
   user_access_end();

Jak píše dále v komentářích, „nebezpečné“ funkce nejsou nutně nebezpečné, používají-li se správně, ale je nutné, aby vývojáři dávali pozor. Makra unsafe_put_user a unsafe_get_user() lze použít pouze po volání user_access_begin() a jako obvykle musí nejprve projít access_ok(). První použití těchto funkcí se nabízí ve funkcích manipulujících s řetězci v uživatelském prostoru. Ve vydání 4.5 je podporována pouze architektura x86, další architektury budou následovat.

Při uzavření tohoto začleňovacího okna bylo začleněno celkem 10 305 neslučovacích sad změn. Trochu to naznačuje, že 4.5 bude docela pomalý vývojový cyklus. Většinu času zpoždění můžeme tentokrát připsat na vrub relativně malému počtu začleněných patchů ze staging tree, jinak pracují vývojáři velmi pilně.

Pokud se dodrží tradiční 63 denní cyklus, můžeme očekávat finální vydání jádra 4.5 13. března. Do té doby je se nejspíš najde a opraví spousta chyb.

       

Komentáře

[Jindřich Makovička]

Takže občas jim musím do mozku vnutit potvrzení této domněnky.

V originále je přesný opak.

[Michal Kubeček]

Ano, překladatel si asi neuvědomil, že "trip an assertion" neznamená "potvrzení té doměnky" (to by v tom kontextu nedávalo smysl), ale vztahuje se konstrukcím/makrům typu assert(), jejichž smyslem je nechat program fatálně selhat, není-li splněna nějaká klíčová podmínka (např. konsistence dat).

[Fluttershy, yay!]

Oops. Díky za upozornění. Ještě něco tam zůstalo?