Jaderné noviny - 4. 8. 2016: Začleňovací okno 4.8, část 2.

14. 8. 2016 | Redakce | Jaderné noviny | 3135×

Stav vydání jádra. Citáty týdne: Dave Chinner a Ingo Molnár. Začleňovací okno 4.8, část 2.

Stav vydání jádra

Začleňovací okno 4.8 je stále otevřeno; viz níže o tom, co již bylo začleněno.

Stabilní aktualizace: tento týden žádné nebyly vydány.

Citáty týdne

Říkám to od samého začátku: se stávajícími souborovými systémy a DAX nedokážeme využít všech možností pmem (perzistentní paměti). DAX má být *provizorním opatřením*, dokud nativní řešení pro pmem nedozrají. To, že se přichází na omezení, jako jsou ta výše, jenom dokladuje skutečnost, že DAX je na ext4/XFS pouze částečným řešením.

Skutečný problém je – jako ostatně vždycky – nedostatek zdrojů na implementaci všeho, co bychom chtěli. Udělat nový souborový systém je těžké, vyžaduje to spoustu času a všichni schopní lidé, které máme, mají plné ruce práce s udržováním dosavadních linuxových souborových systémů a doplňováním podpory věcí jako DAX, které uživatelé chtějí (např. rmap, reflink, copy offload atd.).

-Dave Chinner

ABI zvyšují užitečnost jádra.

-Ingo Molnár

Oprávnění souborů v jádře

Existuje mnoho způsobů, jak v jaderné komunitě udělat špatný dojem. Baole Ni nepochybně narazil na jeden z nich: zveřejnil 1285 samostatných čistících patchů, všechny se stejným předmětem a každý zkopírovaný na dlouhý seznam vývojářů. Byl to David Miller, kdo řekl: „Je to jedno z nejhorších podání série patchů v historii.“ Teoreticky byl cíl patche rozumný: nahradit natvrdo nakódované konstanty jejich symbolickými ekvivalenty. Ale zřejmě jde o příklad, u kterého by komunita viděla čísla raději přímo.

Ona změna se týká míst v jádře, kde jsou specifikována oprávnění souborů – většinou oprávnění soubory, které mají být vytvořeny v sysfs nebo /proc. Pro tato oprávnění existuje sada maker definovaných v <linux/stat.h>, ale mezi uživateli unixových systémů bývá zvykem používat pouze jejich ekvivalenty v osmičkové soustavě. Takže se často můžeme setkat s 0444 místo s S_IRUGO. Vlastně to vypadá, že vzhledem k velikosti sady patchů, které mají z jádra eliminovat oprávnění zadaná oktalově, se s nimi člověk setká alespoň 1285krát.

Samozřejmě se ke způsobu podání sady patchů objevila spousta stížností, ale objevilo se také hodně odpůrců změny samotné. Vypadá to, že pro řadu lidí je řetězec typu 0644 čitelnější než S_IWUSR|S_IRUGO. Nakonec tento přístup potvrdil také Linus, a to se slovy, že by byl nerad, kdyby došlo k začlenění diskutovaných čistících patchů a že by bylo lepší naopak konvertovat makra na oktalový zápis.

Ani oktalový zápis ale není dokonalý. Jak poukázal Al Viro, jsou předmětem drobných, těžko viditelných chyb. Možná, jak bylo navrženo, je skutečný problém v tom, že makra S_* (ze standardu POSIX) jsou těžko čitelná, takže záměry vývojáře spíše zakrývají, než aby je vyjasňovaly. Jako alternativu navrhuje Ingo Molnár přijetí nové sady maker, která je definována takto:

    #define PERM_rw_______	0600
    #define PERM_rw_r_____	0640
    #define PERM_rw_r__r__	0644
    #define PERM_rw_rw_r__	0664
    #define PERM_rw_rw_rw_	0666

Všechny „užitečné“ kombinace mají definovaná makra, zatímco ty nesmyslné nemají žádná. Použití těchto maker by podle Molnára učinilo kód jasnějším a bylo by těžší do něj zavléct bezpečnostní problémy. Avšak jejich začlenění může vyžadovat překonání návyků vývojářů, kteří oktalové konstanty používají již desítky let. Případná diskuze tak nakonec může být ještě delší než sada patchů, která ji vyvolala.

Začleňovací okno 4.8, část 2.

V době psaní tohoto článku bylo Linusem do hlavního repozitáře začleněno již 10 589 neslučovacích sad změn, z toho 7 433 od minulého reportu. Zjevně šlo o rušný týden. Jak už to tak bývá, většina začleněné práce měla formu vnitřních vylepšení, která nejsou na první pohled uživatelům jádra viditelná, ale došlo i na několik zajímavých funkcí.

Mezi ty významnější, uživatelům viditelné patří následující:

• Architektura arm64 nyní podporuje mechanismus kexec (umožňuje zavádět jedno jádro z druhého) a sondy jádra (kernel probes).
• Algoritmus „New Vegas“ pro správu přetížení na úrovni protokolu TCP se dočkal podpory. New Vegas je významnou aktualizací Vegas, přidává například lepší podporu nastavení datových center. Pro podrobnosti viz tento dokument.
• Vrstva mac80211 („WiFi“) se dočkala zajímavých změn pro správu přetížení. Běžné metody řazení horko těžko interagují s mechanismem agregace rámců, používaným bezdrátovými protokoly, vede to k nízkému výkonu. Proto byl kód pro řazení na vrstvě mac80211 zakázán. Místo toho nyní vrstva mac80211 používá férový řadící algoritmus CoDel. Mělo by jít o významné vylepšení vedoucí k výkonnější WiFi na linuxových systémech.
• Protokol spolehlivých datagramových socketů (RDS) umožňuje vytvoření datagramově orientovaných připojení skrze TCP. Ve vydání 4.8 může implementace RDS využívat více TCP připojení k podpoře RDS routingu mezi dvěma hostiteli, což výrazně zlepšuje maximální propustnost. Pro podrobnosti viz tento seznam změn a diskuzi o tom, jak se tento protokol liší od „multipath“ TCP.
• Práce na „expresní datové cestě“ (XDP), popsané v tomto článku, se pohnula kupředu. Ve vydání 4.8 mohou síťové ovladače definovat háček, který umožňuje nahrání programu BPF. Tento program poběží na příchozích paketech ještě předtím, než budou mít nastaveny vnitřní datové struktury. Háček může indikovat, že pakety je třeba zahodit, ale je schopen provádět jednoduché přepisy a přesměrování. U některých typů zátěže to může přinést výrazné zvýšení výkonu bez potřeby překlenovacích technik.
• Jaderný generátor pseudonáhodných čísel byl nahrazen novou implementací, která využívá proudové šifry ChaCha20. Změny se dotkly také řešení problému se škálovatelností v okamžiku, kdy uživatelské programy spotřebovávají obrovské objemy náhodných dat.
• Mechanismus rekultivace stránek subsystému správy paměti byl zásadně přepracován, aby sledoval stránky postavené na uzlech NUMA, místo na paměťových zónách. Jak poznamenal Mel Gorman při zasílání patche, zónová recyklace byla důležitá v době 32bitových systémů se spoustou vysoké paměti, ale nyní běží systémy s velkou pamětí většinou na 64bitových jádrech, kde je rekultivace založená na uzlech vhodnější. Uživatelé by si kromě zlepšení výkonu neměli snad ničeho všimnout. Výsledky testování najdete v oznámení.
• Vývojáři odvedli velký kus práce na tom, aby neprivilegovaní uživatelé mohli připojovat souborové systémy v uživatelských jmenných prostorech. Výsledek se ovšem odvíjí od toho, kolik nedodělků se podaří vyřešit, takže do vývojového cyklu 4.8 se to zřejmě nestihne.
• Jádro získalo podporu standardu Common Architecture Label IPv6 Security Option (CALIPSO). CALIPSO se dá použít k připojení bezpečnostních štítků k paketům, takže se stanou předmětem normální bezpečnostní politiky (SELinux nebo Smack).
• Architektura PowerPC64 nyní obsahuje just-in-time překladač programů BPF.
• Nově podporovaný hardware zahrnuje:
  • Procesory a systémy: jednodeskové počítače Artesyn MVME7100, SoC R-Car V2H (R8A7792) a Broadcom BCM23550.
  • Audio: převodníky stereo PDM na I2S/TDM Analog Devices ADAU7002, kodeky Cirrus Logic CS53L30 a CS35L33, mono hlasové kodeky Maxim MAX9860, reproduktorové zesilovače Maxim MAX98504 a audio rozhraní Allwinner A10 I2S.
  • Grafika: displejové procesory ARM Mali, RGB/HDMI můstky Silicon Image sii02x a eDP můstky Toshiba TC358767.
  • Vstupy: kapacitní dotyková tlačítka Atmel, SPI dotykové obrazovky Ntrig/Microsoft Surface 3, I2C dotykové obrazovky Raydium, grafické tablety Pegasus Mobile Notetaker Pen a I2C HID touchpady a trackpointy (StickPointers) Alps.
  • Různé: dvoukanálové LED řadiče TI LP3952, periferní načítače obrazu Qualcomm Hexagon V5, XOR enginy Marvell verze 2, DMA enginy Xilinx ZynqMP, generátory taktu R-Car R8A7796, jednotky řízení taktu Allwinner H3, řadiče taktu AmLogic S905, PCI hotplug řadiče PowerPC PowerNV, časovače Aspeed 2400 a Maxim Max77620, SoC časovače Amlogic Meson GXBB, SDIO/SD/MMC hostitelské řadiče Broadcom STB, správci schránky Broadcom PDC, systémové zdrojové čipy Altera Arria10 DevKit, řadiče externích sběrnic Atmel, řadiče sběrnic Tegra ACONNECT, SPI-NOR flash řadiče HiSilicon, NFC nand řadiče MediaTek SDG1 NFC, SPI řadiče Atmel Quad, SPI řadiče Cadence Quad a PCIe řadiče Aardvark.
  • Sítě: HDLC řadiče Freescale QUICC, ethernetové přepínače Broadcom BCM53xx, PCIe PHY Broadcom Northstar2, PHY Intel XWAY, CAN FD řadiče Renesas R-Car, rychlé řadiče Ethernet MAC Hisilicon a SoC řadiče MDIO sběrnic APM X-Gene.
  • Správa pinů: SoC řadiče z rodiny Oxford Semiconductor OXNAS, řadiče Maxim MAX77620/MAX20024, SoC řadiče UniPhier PH1-LD11 a PH1-LD20, řadiče Intel Merrifield, Broadcom NSP, Qualcomm 9615 a SRMicroelectronics STM32F746.

Změny viditelné vývojářům zahrnují následující:

• Byly začleněny patche infrastruktury zásuvných modulů GCC, takže je možné upravovat proces sestavení jádra pomocí zásuvných modulů překladače. V době psaní tohoto článku byly začleněny zásuvné moduly pro testování pokrytí a výpočet cyklomatické složitosti. Zásuvný modul „latentní entropie“, který se snaží generovat entropii v rané fázi procesu bootstrap, byl v době psaní tohoto textu ve stádiu žádosti o začlenění.
• Nový mechanismus skb_array přidává FIFO datovou strukturu založenou na polích a určenou k řazení síťových paketů. Pro přehled o API viz <linux/skb_array.h>.
• Úkol přepracovat mechanismus pro hotplug CPU pokračuje s přeměnou více oznamovatelů do nového režimu. Jak poznamenal Thomas Gleixner v žádosti o začlenění: „Dalších 700 řádků neproniknutelného bludiště je pryč.“

Začleňovací okno 4.8 bylo v době psaní tohoto článku ještě otevřeno, takže můžeme očekávat další funkce, než dojde k vydání 4.8-rc1. V příštím dílu se budeme věnovat posledním změnám, které v tomto vývojovém cyklu čeká začlenění.

       

Komentáře

[filbar]

ethernetové přepínače Broadcom BCM53xx

- jsou to ty co jsou osazené na Banana PI R1 - https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/net/phy/b53/Kconfig?rev=35305 - bo je to jiný?

[chrono]

Je to to isté len to niekto upravil pre Linux 4.8.

[chrono]

... a postaral sa o to, aby to bolo konečne začlenené.

[Jendа]

OT: tohle je poprvé, kdy vidím někoho z Ostravy použít bo ve smyslu nebo. Do teď jsem si myslel, že jediný validní význam je zprava asociativní binární operátor značící kauzalitu. Je to omyl nebo se to fakt takhle začalo používat i jinde než v nepovedených emulacích ostravštiny neostraváky?

[Honza Jaroš]

Moje žena je prajzačka od Hlučína a když náhodou ze srandy (ale nikoli parodicky) spustí po jejich, bo se v jejím projevu běžně vyskytuje...

[toy]

Ale v jakém významu? To je to, oč tu běží.

[Tom K]

Ostravsky bo je jen zkratka anglickeho 'because of'.

[Honza Jaroš]

Z kontextu vždy vyplývá něco ve smyslu "protože" či "neboť". Čili v tom prvním příspěvku (který jsem šťastně minul, přiznávám) to neodpovídá, tam pisatel evidentně zkrátil "nebo"...

[Honza Jaroš]

Aha, on o tom píše i Jenda. Hmm, je vidět, že když jsem to psal, ještě nebylo devět a nebyl jsem plně při smyslech...

[Semo]

SK lebo == CZ protoze

SK alebo = CZ nebo

SK bo (nespisovne) == SK lebo == CZ protoze

[Radovan Garabik]

V SK je bo spisovné. Len poetické.

[🇵🇸]

použít bo ve smyslu nebo

*ve smyslu moderního „nebo“ – historicky se „nebo“ používalo jako dnes „protože“, leč z toho se dochovalo pouze „neboť“