Jaderné noviny - 7. 1. 2009

12. 2. 2009 | Jirka Bourek

Články - Jaderné noviny - 7. 1. 2009  

Aktuální verze jádra: 2.6.28. Citáty týdne: Matthew Garrett, Alan Cox, Christoph Hellwig, Linus Torvalds, Greg Kroah-Hartman, Ted Ts'o. Začleňovací okno 2.6.29, část první. Budoucnost grsecurity. Btrfs míří do hlavní řady.

Obsah

• Aktuální verze jádra: 2.6.28
• Citáty týdne: Matthew Garrett, Alan Cox, Christoph Hellwig, Linus Torvalds, Greg Kroah-Hartman, Ted Ts'o
• Začleňovací okno 2.6.29, část první
• Budoucnost grsecurity
• Btrfs míří do hlavní řady

Aktuální verze jádra: 2.6.28

Začleňovací okno 2.6.29 je otevřené, takže v době psaní tohoto článku není žádná vývojová verze jádra. Do 2.6.29 byl začleněn docela velký kus práce; detaily vizte v samostatném článku níže.

Současné stabilní jádro 2.6 je 2.6.28, vydané Linusem 24. prosince. Mezi nejvýznamnější změny v tomto jádře patří přidání správce GPU paměti GEM, souborový systém ext4 již není "experimentální", zlepšení škálovatelnosti ve správě paměti pomocí přepracovaného vmap() a patchů škálovatelnosti odstraňování stránek, přesunutí ovladačů -staging do hlavní řady a mnoho dalších. Spoustu dalších detailů o 2.6.28 vizte ve skvělém shrnutí na KernelNewbies. Linus říká: Dokonce i když máte přátele nebo rodinu, nechte je jejich nekončícímu pachtění se s vánočním řízkem nebo kaprem a během noci, až budou spát, jim můžete nadělit kouzelný dárek nově aktualizovaného počítače. Až se zítra ráno probudí, řekněte jim, že jste viděli Ježíška s USB diskem v ruce, jak aktualizoval OS všech hodných chlapců a děvčat.

Citáty týdne: Matthew Garrett, Alan Cox, Christoph Hellwig, Linus Torvalds, Greg Kroah-Hartman, Ted Ts'o

Zásada pro vývoj softwaru: Všechno je na hovno a pokusí se tě to zabít, když se k tomu otočíš zády.

-- Matthew Garrett

Neřekl bych, že "automaticky znič mojí sbírku hudby" je rozumné výchozí nastavení

-- Alan Cox

BTW, současný nával vysoce komplexních souborových systémů mě rozhodně trochu znervózňuje.

-- Christoph Hellwig

Mohl bys poslat ten patch, abychom se mohli podívat, jestli v najdeme nějakou hloupou chybu, kvůli které bychom se ti pak mohli posmívat?

-- Linus Torvalds (Díky Jeffu Schroederovi)

Je zde spousta věcí, jak lze vidět z konečných čísel diffstatu:

779 souborů změněno, 472695 vložení (+), 26479 výmazů (-)

a jo, všechno je to svinstvo :)

-- Greg Kroah-Hartman

Jenom s trpkostí poznamenám, že jádra 0.9x jsem na 40MHz 386 měl přeložená za 10 minut. O nějakých 15 let později trvá překlad jádra přibližně stejnou dobu, i když se počítače od té doby velice zrychlily. Na tom se zdá být něco špatně...

-- Ted Ts'o

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

V době psaní tohoto článku bylo do vývojového cyklu 2.6.29 přijato nějakých 6500 neslučovacích sad změn. Je to obvyklá sada nových ovladačů zařízení společně s mnoha důležitými změnami vnitřku jádra.

V době psaní tohoto článku mezi změny viditelné pro uživatele patří:

• Nové ovladače pro:

  • procesory SH7201 založené na FPU SH-2A,
  • audio zařízení Palm T|X, T5 a LifeDrive,
  • audio zařízení Gumstix Overo,
  • audio zařízení Marvell Zylonite,
  • kodeky Wolfson Micro TWL4030, UDA134x, WM8350 AudioPlus a WM8728,
  • audio zařízení Texas Instruments SDP3430,
  • audio zařízení OMAP3 Pandora,
  • integrovaný HDMI audio kodek Intel G45,
  • síťové zařízení Broadcom BCM50610,
  • síťové zařízení LSI ET1011C,
  • ethernetové zařízení KS8695,
  • PCI ethernetový adaptér SMSC LAN9420,
  • embedded ethernetové řadiče SMSC LAN911x a LAN921x,
  • síťové řadiče Solarflare 10Xpress SFT9001,
  • čipsety Atheros AR9285,
  • víceportové ADSL2+ PCI karty Solos,
  • CPU Nuvoton W90X900,
  • video zachytávající zařízení LG ATSC lgdt3304,
  • ISDB-T zařízení Sharp s921,
  • křemíkové tunery ST Microelectronics STB6100 a vícestandardové frontendy STB0899,
  • na ST STV06XX založené kamery,
  • 8PSK/QPSK tunery TDA8261,
  • kamery OmniVision ov772x,
  • tunery Conexant CX24113/CX24128,
  • video dekodéry Texas Instruments TVP514x,
  • kamery OMAP2 (k vidění v internetových tabletech Nokia),
  • FM radio zařízení NXP TEA5764 I2C,
  • iSCSI adaptéry založené na Chelsio T3 ASIC,
  • jednotky správy napájení Wolfson Microelectronics WM8350,
  • nabíječky baterií Dialog DA9030,
  • EVM mikrokontroléry DaVinci DM355,
  • čipsety řadiče paměti Intel 5400 (Seaburg),
  • RC vysílače Walkera WK-0701,
  • sériové touchscreeny Wacom W8001 penabled,
  • touchscreeny Dialog Semiconductor DA9034,
  • touchscreeny založené na TSC2007,
  • trackballové myši PXA930 a
  • vylepšené rotační řadiče PXA930/PXA935

• Mnoho nových ovladačů se do jádra dostalo také přes strom staging; mezi ně patří ovladače pro:

  • video zachytávající zařízení Sensoray 2250/2251,
  • bezdrátové čipy Airgo AGNX00,
  • širokou škálu zařízení zachytávající data pomocí frameworku Comedi,
  • laptopové OLED displeje ASUS,
  • bezdrátová rozhraní Ralink 2860 a 2870 wireless (To je ovladač Ralink RT2860 od té společnosti, která dělá otřesné věci jako čtení konfiguračního souboru z /etc.),
  • bezdrátové síťové adaptéry RealTek RTL8187SE,
  • LCD panely pro paralelní port HD44780 nebo KS-0074,
  • síťová rozhraní ServerEngines BladeEngine (EC 3210),
  • USB kamery Princeton Instruments,
  • interaktivní tabule Mimio Xi,
  • síťový stack openPOWERLINK
  • zařízení Frontier Tranzport a Alphatrack a
  • několik rodin desek pro získávání dat Meilhaus.

  Také byla přidána, zdánlivě bez pomoci Google, sada ovladačů pro platformu Android, včetně podpory pro IPC mechanismus /dev/binder, časované GPIO operace, RAM buffer konzoli - zvláštního zařízení "zabijáka při nedostatku paměti" [low memory killer] - a logovací zařízení

  Pamatujte, že "staging" ovladače nejsou považovány za ovladače dosahující kvality jaderného kódu; jsou začleněny s nadějí, že je vývojáři pomohou zlepšit. Přes strom staging bylo tentokrát začleněno poměrně hodně zlepšení těchto ovladačů, takže se zdá, že strom funguje tak, jak bylo zamýšleno.

• Po dlouhou dobu zavržený ovladač eepro100 byl konečně odstraněn; místo něj by měl být používán ovladač e100.

• SCSI vrstva získala podporu pro zařízení Fibre Channel over Etherner (FCoE).

• Kód ovladače GEM vrstvy používané pro správu paměti v jednotkách grafického procesoru (GPU) se dočkal mnoha vylepšení. Velkou novinku v této oblasti je nicméně to, že byl konečně začleněn kód pro jaderné nastavování režimu [kernel mode setting]. Tato změna dláždí cestu pro odstranění velké části děsivého kódu v uživatelském prostoru, lepší podporu pro vlastnosti jako rychlé přepínání uživatelů a schopnost X serveru běžet bez oprávnění superuživatele. Jaderné nastavování režimu je nicméně v počátečním stádiu a většina lidí by ho neměla zapínat, pokud si nebudou jisti, že mají správně připravený uživatelský prostor.

• Do kódu architektury arm byla přidána podpora pro systémy HP iPAQ h5000, systémy založené na sérii Samsung S3C64XX a herní konzole Pandora.

• Architektura SuperH získala podporu pro sledovací framework ftrace.

• Je zde nová boot volba no_file_caps=, kterou lze použít pro zakázání kvalifikací souborů [file capabilities] u jader, která mají tuto vlastnost povolenu. Z changelogu: To distributorům umožňuje dodávat jádro se zakompilovanými kvalifikacemi souborů bez toho, aby byli uživatelé nuceni je používat (a rozumět a důvěřovat jim).

• Souborový systém CIFS podporuje novou volbu při připojování forcemand; když je použita, zajistí, že CIFS používá povinné zámky [mandatory locks] místo nepovinných zámků [advisory locks].

• V síťové vrstvě jsou nyní podporovány algoritmus omezující TCP zácpu CUBIC 2.3 [TCP congestion control algorithm] a vlastnost "zpětné upozornění na zácpu" [backward congestion notification].

• Síťovací kód má nyní podporu pro algoritmus plánování paketů "deficitní round robin", o kterém se tvrdí, že má zajistit vysoce férové plánování s minimálními náklady.

• Byla začleněna rozsáhlá sada patchů síťových jmenných prostorů. Vývojáři jmenných prostorů se zatím zdrželi tvrzení, že je tato vlastnost připravena na všeobecné používání, ale musí se tomu blížit.

• Souborový systém devpts nyní podporuje vytvoření několika instancí v různých jmenných prostorech.

• Kód pro regulaci bezdrátových zařízení podle domény [wireless regulatory domain] byl rozšířen, aby podporoval 802.11d.

• Sada patchů stromového RCU, která by měla poskytnout vylepšenou škálovatelnost na systémech s "více než pár sty procesorů", byla začleněna.

• Uživatelé velkých stránek se nyní mohou podívat do /proc/pid/smaps na novou hodnotu KernelPageSize, která udává skutečnou velikost stránek, které se používají. Mezi jinými věcmi lze tuto informaci využít pro ověření toho, že proces opravdu využívá velké stránky tam, kde se to očekává.

• Souborový systém eCryptfs nyní podporuje šifrování jmen souborů stejně jako jejich obsahu.

• Mechanismus souborového systému v uživatelském prostoru FUSE nyní může podporovat volání ioctl() a poll().

• Do bezpečnostního modulu SMACK byla přidána podpora pro neoznačené sítě a hostitele.

Změny viditelné pro jaderné vývojáře zahrnují:

• Nové synchronní hashovací rozhraní nazvané "shash" zjednodušuje použití synchronních hashovacích operací a přitom umožňuje použít stejné tfm simultánně v různých vláknech. Všichni uživatelé ve stromě byli přepnuti na nové API.

• Ohromná sada patchů osobních údajů [credentials] byla začleněna. Tento kód reorganizuje správu osobních údajů procesu (ID uživatele, kvalifikace atd.). Jedním z okamžitých důsledků této změny je to, že přímé odkazování se na pole zaměřená na osobní údaje ve struktuře úlohy musí být změněno; například current->user->uid se mění na current_uid(). Popis nového API vizte v Documentation/credentials.txt.

• Kód ftrace se dočkal mnoha interních změn. Sledování funkcí bylo v mnoha ohledech vylepšeno a vývojáři přidali mechanismus pro profilování chování příkazu if, poskytnutí grafu volání funkcí, získání sledování zásobníku v uživatelském prostoru a sledování přechodů mezi stavy napájení.

• Většina funkcí/metod zpětných volání spojených se strukturou net_device byla z této struktury přesunuta do nové struct net_device_ops. Ovladače ve stromě byly konvertovány na nové API.

• Ze struktury struct net_device; bylo odstraněno pole priv; ovladače by místo něj měly používat netdev_priv().

• Obecná PHY vrstva má nyní podporu pro správu napájení. Za tímto účelem byly do struct phy_driver přidány dvě nové metody - suspend() a resume().

• Síťová vrstva nyní podporuje operaci odlehčování při rozsáhlém příjmu [large receive offload] (či "obecné odlehčování při příjmu")

• API NAPI bylo trochu pročištěno. konkrétně funkce jako netif_rx_schedule(), netif_rx_schedule_pred() a netif_rx_complete() ztratily nepotřebný parametr struct net_device.

• Kód časovačů s vysokým rozlišením byl zjednodušen odstraněním proměnných režimů funkcí zpětných volání. Všechno zpracování nyní probíhá v kontextu tvrdého IRQ (hardirq)

• Byla přidána nová sada LSM háčků [hooks]; tyto podporují bezpečnostní operace založené na cestách se jménem [pathname]. Se začleněním těchto háčků byla odstraněna jedna hlavní překážka začlenění bezpečnostních modulů jako AppArmor a TOMOYO.

• Jádro se nyní odmítne přeložit s GCC 4.1.0 nebo 4.1.1; tyto verze mají nepříjemné chyby, které brání vytvoření funkčního jádra. Verze 3.0 a 3.1 byly také prohlášeny za příliš staré a v 2.6.29 nebudou podporovány.

• Ovladače Video4Linux nyní používají oddělenou strukturu v4l2_file_operations, ve které se ukládají jejich jako-VFS zpětná volání. Prototypy mnoha z těchto funkcí byly změněny, byl odstraněn parametr inode.

• Video4Linux2 nyní získal koncept "podzařízení", který má odrážet fakt, že video "zařízení" ve skutečností bývá sestava několika spolupracujících zařízení. Popis toho, jak tento mechanismus funguje, vizte v novém dokumentu.

• Dvě nové funkce - stop_machine_create() a stop_machine_destroy() - umožňují nezávislé vytváření vláken používané stop_machine(). To umožňuje vytvořit tato vlákna před skutečným pokusem stroj zastavit, čímž je celá operace odolnější proti selhání.

• Souborová operace poll() nyní může spát; více informací o této změně vizte v tomto článku.

• Mechanismus masek CPU, který se používá k reprezentaci sady procesorů v systému, je uprostřed rozsáhlého přepracování. Problém spočívá v tom, že masky CPU se často ukládají na zásobník, ale s tím, jak počet CPU roste, na zásobníku není pro masku dost místa. Nové API je navrhováno tak, aby tyto masky ze zásobníku zmizely a aby existovala ochrana proti tomu, kdyby se někdo někdy snažil je tam uložit. Detaily o této práci vizte v tomto oznámení od Rustyho Russela.

Začleňovací okno bylo otevřeno 28. prosince; jestliže přetrvá obvyklý dvoutýdenní vzor, změny by měly být přijímány do 11. ledna. Nalaďte si nás příští týden a dozvíte se aktuální informace o posledních patchích začleněných do jádra 2.6.29.

Budoucnost grsecurity

Používání jaderného patche mimo strom má několik nevýhod, ale dokud je patch udržován a aktualizován s jádrem, je to možné. Když vývojáři ztratí zájem - nebo financování - pro uživatele z toho je mnohem větší problém. K tomuto stavu možná dojde pro uživatele nástroje grsecurity, protože nedávné vydání přichází s varováním, že by mohlo být poslední.

Není překvapivé, že uživatelé grsecurity mají obavy o budoucnost tohoto bezpečnostního nástroje, ale volání po začlenění do hlavní řady pravděpodobně nebude úspěšné. Postupem času, zejména díky snaze lidí mimo projekt, se různé části grsecurity (a s ním spojeného projektu PaX) dostaly do jádra, ale z mnoha důvodů kompletní patch v hlavní řadě není; základní důvod je ten, že vývojáři, jak se zdá, nemají zájem nebo nechtějí dodržovat standardní cestu pro začlenění.

Patch grsecurity implementuje mnoho bezpečnostních funkcí, které jsou užitečné obzvláště pro webové servery nebo servery, které nedůvěryhodným uživatelům poskytují přístup k shellu. Jednou z hlavních vlastností je řízení přístupu založené na roli [role-based access control, RBAC], která je alternativou k tradičnímu UNIXovému volnému řízení přístupu [discretionary access control, DAC] nebo novějšímu povinnému řízení přístupu [mandatory access control, MAC] poskytovanému SELinuxem nebo Smack. Cílem RBAC je vytvoření systému s "nejmenšími právy", kde uživatelé a procesy mají jenom nejnutnější práva potřebná k provedení svých úkolů. grsecurity také zahrnuje vytvrzení systémového volání chroot(), aby se eliminovalo povýšení práv a další slabiny "vězení v chrootu" [chroot jail]. Navíc je zde mnoho dalších různých vlastností jako auditování a omezení přístupu k informacím v /proc, všechny vlastnosti jsou vyjmenovány na stránkách grssecurity.

Další důležitou komponentou grsecurity je kód PaX, který omezuje přístup k paměti, takže jsou různé exploity jako přetečení bufferu a další slabiny při vykonávání kódu otupeny nebo eliminovány. Toho se dosahuje tak, že jsou datové stránky nastaveny jako nespustitelné použitím - nebo emulací - bitu "nevykonávat" (NX). PaX omezuje mprotect(), aby nepřipouštěl stránky, které jsou zapisovatelné a zároveň spustitelné, aby se také zabránilo vkládání kódu. Také přidává mnohem agresivnější znáhodňování rozvržení adresového prostoru (ASLR) než to, které nyní Linux používá. PaX je vyvíjen odděleně od grsecurity anonymním "PaX týmem" a začleňován do grsecurity vývojářem Bradem Spenglerem.

Projekt je tu po dlouhou dobu; grsecurity začal v roce 2001, PaX roku 2000. Je mnoho spokojených uživatelů a grsecurity se používá v distribucích jako NetSecL a Hardened Gentoo, ale nikdy se nedostalo do hlavní řady jádra. Gábor Micsko nedávno zaslal Linusu Torvaldsovi žádost na linux-kernel, aby grsecurity znovu zvážil:

Obecným názorem vývojářů grsecurity, PaX a jejich uživatelů je, že kromě nalezení jiného dlouhodobého sponzora by přijetí kódu do jádra bylo nejlepším řešením pro záchranu projektu.

Linus odpověděl, že většina toho, co je v grsecurity a PaX je šílený a velmi obtěžující a invazivní kód. Pak pokračoval vylíčením části historie:

Zjevná neschopnost (a co je možná důležitější - naprostá neochota) PaX týmu vidět, co má dlouhodobě smysl v obecném jádře, a co ne, rozdělit věci a ty rozumné tlačit nahoru (a vědět, které věci jsou příliš ošklivé nebo specializované na to, aby dávaly smysl) způsobily, že většina funkcí PaX nikdy nebyla začleněna.

Velká část byla začleněna během let (většinou protože si někdo strávil čas tím, že věci rozdělil), ale ne, nezačneme najednou začleňovat kód jenom proto, že projekt má problémy. Žádný ze základních problémů nebyl vyřešen.

Perfektní příklad neochoty spolupracovat s jadernými hackery je ztělesněn v rozhodnutí neimplementovat RBAC jako linuxový bezpečnostní modul (LSM). Ať už je to dobře, či ne, LSM je mechanismus, který implementuje řízení přístupu v jádře. Koncepčně se hodí k RBAC kódu grsecurity. Možná by byly zapotřebí nějaké LSM háčky navíc, ale zapracování na přidání těchto háčků je správný přístup. O LSM panovala jednu dobu nejistota, ale dnes je to zjevně cesta kupředu.

Dalším problémem kódu PaX by mohlo být to, že není povoleno anonymní přispívání do jádra. Pravděpodobně Brad nebo jiný zaujatý vývojář by mohl tento kód podepsat, ale přímo od "PaX týmu" být přijat nemůže.

V rozsahu, v jakém byly grsecurity a PaX navrhovány k začlenění, byly vždy prezentovány jako jediný monolitický patch. Nikdy nedošlo k pokusu rozdělit patch na logické části, které by bylo možné přijmout nebo odmítnout podle jejich individuálních hodnot. Doteď k tomu nedošlo ani poté, co projekt ztratil sponzora; čekání do poslední chvíle ale nebude fungovat, jak to říká Robert Hancock:

Říct jaderným vývojářům "vezměte tenhle velký kus kódu a hoďte ho do svého jádra, protože když to neděláte, tak si sebereme svůj míček a jdeme domů," není způsob, jakým to tu funguje.

Pokud má existující kód svou hodnotu, zainteresování uživatelé a vývojáři musí pracovat podle obvyklých způsobů, aby byl začleněn. To znamená, že je potřeba identifikovat užitečné kousky a postupovat odtud. Valdis Kletnieks navrhuje:

Pravděpodobně nejlepší způsob, jak pokračovat, by byl, aby se zainteresování shodli na tom, co jsou "rozumné záležitosti" (což by se mohlo změnit na zajímavý boj o jídlo), tyto věci oddělit a navrhnout je k začlenění v samostatných oddělených větvích.

Opět se jedná o další příklad nebezpečí kódu mimo strom. Podle všech měřítek má grsecurity spokojené uživatele, kteří budou opuštěni, pokud projekt grsecurity nesežene do konce března sponzory. Uživatelé mohou samozřejmě nadále provozovat o grsecurity vylepšená jádra, která v současnosti mají, ale nebudou moci využít pokroky v nadcházejících vydáních jádra.

Zainteresovaní uživatelé se možná shromáždí a budou aktualizovat grsecurity podle nových jader, ale to stále nemění základní problém, že by lépe udělali, kdyby strávili alespoň část svého času tím, že budou spolupracovat s jadernými vývojáři, aby bylo co nejvíc z grsecurity a PaX začleněno do hlavní řady.

Btrfs míří do hlavní řady

Souborový systém Btrfs byl vyvíjen poslední rok nebo tak nějak; po většinu tohoto času byl považován za nejpravděpodobnější "souborový systém nové generace" pro Linux. Nicméně předtím, než bude moci o tento titul usilovat, se Btrfs musí stabilizovat a najít cestu do hlavní řady jádra. Vývojář Btrfs Chris Mason již nějakou dobu říká, že kód se dá dohromady rychleji, pokud bude začleněn relativně brzo, i když ještě není doopravdy připraven na produkční nasazení. Obecná zkušenost s vývojem jádra toto tvrzení podporuje: kód ve stromě je revidován, testován a opravován více než kód mimo strom. Komunita vývojářů tedy v rozumných mezích podporovala relativně brzké začlenění Btrfs.

V poslední epizodě Andrew Morton navrhl, že cílem by mělo být začlenění do 2.6.29. Chris by byl rád, kdyby k tomu došlo, za tímto účel zaslal verzi Btrfs ke zvážení. Není překvapující, že toto zaslání ještě zvýšilo zájem, který byl tomuto kódu věnován; výsledkem bylo, že Chris rychle obdržel seznam věcí, které je potřeba opravit. Většina z nich byla nyní vyřešena, ale zbývá několik záležitostí, které by mohly zabránit začlenění Btrfs v tomto vývojovém cyklu. Tento článek se dívá na potenciální překážky.

Jednou z nich je API pro uživatelský prostor. Btrfs s sebou přináší celou sadu nových ioctl() volání, žádné z nich přitom nebylo významněji revidováno nebo dokonce zdokumentováno. Tato volání provádějí funkce, jako je vytváření snapshotů, zahájení defragmentace, vytváření nebo změny velikosti podsvazků, přidávání zařízení do sady zařízení atd. Zajímavé je, že se neobjevily žádné významné stížnosti na vlastnosti správy svazků v Btrfs obecně. Rozhraní k takovýmto vlastnostem nicméně vyžaduje podrobné prozkoumání; API pro uživatelský prostor normálně nesmí být narušeno poté, co je začleněno do hlavní řady. Padly nějaké návrhy, že by u Btrfs byla učiněna výjimka, protože je velmi malá šance, že by systémy začaly být závislé na specifickém rozhraní předtím, než bude Btrfs připraveno k nasazení.

Nicméně i tak až distribuce začnou dodávat nástroje pro Btrfs - aby pomohly testerům, když nic jiného - způsobí změna API problémy. Jakýkoliv potenciál pro tento druh problémů by značně ztížil změny, Linux by tak mohl skončit s raným API Btrfs. Vzhledem k tomu, že přinejmenším jeden vývojář si myslí, že toto API je nutné významně přepracovat, mohla by se tato záležitost změnit ve významnou překážku.

Pak je zde záležitost zamykacích primitiv pro zvláštní účely, které Btrfs používá. Aby bylo možné této diskuzi porozumět, stojí za to se podívat na zamykací funkci použitou uvnitř Btrfs:

int btrfs_tree_lock(struct extent_buffer *eb)
    {
    int i;

    if (mutex_trylock(&eb->mutex))
        return 0;
    for (i = 0; i < 512; i++) {
        cpu_relax();
        if (mutex_trylock(&eb->mutex))
        return 0;
    }
    cpu_relax();
    mutex_lock_nested(&eb->mutex, BTRFS_MAX_LEVEL - btrfs_header_level(eb));
    return 0;
    }

Zámek, o který se jedná, je mutex, ale je získáván poněkud zajímavým způsobem. Jestliže je držen jiným procesem, funkce se ho bez spaní pokusí získat 512krát s nadějí, že bude rychle dostupný. Pokud se tak stane, zámek lze získat úplně beze spaní. Po 512 neúspěšných pokusech se funkce konečně vzdá a uspí se.

Chris toto chování ospravedlňuje takto:

Btrfs používá mutexy k ochraně bloků b-stromů a prohledávání b-stromů často zasáhne horké uzly, které jsou vždy v cache. Pro tyto uzly jsou opakované pokusy ve smyčce mnohem rychlejší; btrfs se nicméně také potřebuje umět uspat, když je držen zámek, aby mohlo číst z disku nebo dělat jiné složité operace.

Výkonnost dbench 50 se u btrfs s nepodmíněným opakováním zdvojnásobuje, většinou protože se téměř vždy pracuje s daty v RAM. Pro 50 procesů, které paralelně vytváří 4k soubory, je opakování o 30-50 % rychlejší. Tato zátěž je směs toho, co je závislé na disku, a toho, co je závislé na CPU.

Zdá se, že má cenu jít za takto významným nárůstem výkonnosti. Ve skutečnosti to odráží fenomén, který byl pozorován i v jiných situacích: i když jsou používány spící zámky, výkonnost se často zlepší, když se procesor po nějaký čas opakovaně snaží získat zámek, o který se soupeří, s nadějí, že bude za chvíli k dispozici. Pokud lze zámek získat bez spaní, odpadne režie spojená s uspáním procesu a jeho opětovným probuzením. Kromě toho je zde fakt, že proces, který se snaží získat zámek, je pravděpodobně z větší části nahrán v cache CPU. Umožnit tomuto procesu dál běžet téměř určitě povede k lepšímu výkonu systému, pokud je zámek získán rychle.

Z tohoto důvodu byl minulý rok vyvíjen patch adaptivních zámků v reálném čase, i když si nikdy nenašel cestu do hlavní řady. V reakci na diskuzi o Btrfs Peter Ziljstra navrhl patch točícího se mutexu [spinning mutex patch], který má poskytnout stejné výhody jako zamykací funkce použitá v Btrfs, ale pro všeobecnější použití a bez magických konstant. V Peterově patchi se snaha získat zámek, o který se soupeří, opakuje tak dlouho, dokud proces držící daný zámek skutečně běží na některém CPU. Jakmile se držitel zámku uspí, jakýkoliv proces snažící se získat zámek se také uspí. Heuristika dává smysl, detailní benchmarky však zaslány nebyly. Patch byl přijat vcelku dobře, Linus nicméně trval na některých změnách.

Obecnější točící se mutex tedy může najít svou cestu do hlavní řady, jestli se tam ale dostane v 2.6.29, to není jasné. Vývojáři většinou chtějí, aby jejich vnitřní zamykací primitiva byla rozumně dobře otestována; začlenění něčeho, co bylo vyvinuto těsně před koncem začleňovacího okna, by mohlo být obtížné. Dokud se něco takového nestane, Chris nemá zájem odstranit svou zvláštní zamykací funkci:

Pokud ale někdo, kdo pracuje na adaptivních zámcích pro své zamykací schéma, hledá programátora, testera, příklad využití nebo benchmark, hlásím se. Do té doby je tohle můj for cyklus, je mnoho podobných, ale tenhle je můj.

Nakonec je tu otázka pojmenování. Někteří revidovatelé navrhli, že by souborový systém měl být začleněn pod jménem, které dává najevo, že není míněn pro produkční nasazení - "btrfsdev" například. Chrisovi se tento nápad nelíbí, poznamenává k němu, že na rozdíl od existujících souborových systémů je Btrfs znám tím, že je nový a nemá žádnou reputaci stability. Prohlásil nicméně, že je ochoten tuto změnu provést, pokud bude opravdu považována za nutnou. Bruce Fields upozornil na to, že nazývat ho "Btrfs" od začátku by mohlo poškodit budoucí vývojáře, kteří nabootují staré jádro (s neprodukční verzí Btrfs) po přepnutí na novou verzi, která je připravena k nasazení.

To všechno pro Btrfs v 2.6.29 znamená nejistý osud; je zde vcelku slušné množství otevřených záležitostí a blíží se konec začleňovacího okna. Je samozřejmě možné začlenit Btrfs po 2.6.29-rc1; vzhledem k tomu, že je to zcela nový subsystém, nezpůsobí regrese, ale jestliže se Linus rozhodne, že je v současném kódu Btrfs příliš mnoho nedotažených záležitostí, může se prostě rozhodnout dát mu další vývojový cyklus před začleněním do hlavní řady. Takže i když nikdo asi nepochybuje o tom, že Btrfs bude začleněn, stále je tu otázka kdy.

(Pokud se usměje štěstí, doufáme, že v některých z následujících Jaderných novin budeme mít rozhodný článek o Btrfs, jakmile ho autor sepíše. Nepřepínejte.)

Diskuse k tomuto článku

[Marex]

"audio zařízení Palm T|X, T5 a LifeDrive"

to je zase preklad smarja ... to co tam bylo zaclenene je ASoC audio driver pro Palmy (cili velmi zjednodusene specializace driveru pro zvukovy chip na vyse zminenych Palm.* zarizenich - coz jsou kapesni pocitace (tzv. PDA)). Kvalita prekladu zacina pokulhavat

[Marex]

"audio zařízení Marvell Zylonite" tohle taky ... Zylonite je nakej board, ne zvukovka.

[cronin]

Mne udrela do očí veta "... poskytovanému SELinuxem nebo Smack", kde prvý názov je vyskloňovaný a druhý nie je.

Na rôzne násilné preklady som si už zvykol a nevadia mi, pretože tak či tak v konečnom dôsledku prakticky okamžite alebo po preklade späť do angličtiny pochopím, o čo sa jedná. Čo ma ale nedávno v JN takmer zrazilo zo stoličky bolo "... rosyp/zbieraj IO". Považujem skôr za náhodu, že viem čo to scatter/gather je. Keby som to nevedel, možno by som sa to pokúsil nájsť. Nájsť to v slovenične či češtine je prakticky nemožné, v angličtine to kamoš Google dopĺňa už pri písaní do vyhľadávacieho textboxu. Nakoniec už len rečnícka otázka: Keď už je preložené scatter/gather, prečo nie je preložené aj to IO tesne za tým?

[Robert Krátký]

Mne udrela do očí veta "... poskytovanému SELinuxem nebo Smack", kde prvý názov je vyskloňovaný a druhý nie je.

SMACK je zkratka. Kdyby se to jmenovalo SMACKLinux, tak bych skloňování chápal.

[happy barney]

<abbr title="Simplified Mandatory Access Control Kernel">SMACK</abbr>

by v tom prípade bolo asi vhodnejšie

[cronin]

V takom prípade sa k nesklonnej skratke pridá sklonovateľný predmet: "... poskytovanému SELinuxem nebo SMACK systémem." Kde je vôľa, tam je cesta. Keď už je SMACK skratka, treba ju písať veľkými písmenami. Je možné oponovať argumentom, že samotní autori používajú "Smack". Na to sa da spýtať, kde sa vzala verzia napísaná veľkými písmenami v prvej kapitole týchto JN. Chcem len povedať, že v tak technickom texte ako sú JN musí snaha za každú cenu dodržať pravidlá slovenského/českého jazyka stroskotať. Nevadia mi preklady anglických termínov do češtiny či slovenčiny, ani mi nevadí ponechanie pôvodných názvov, pokiaľ čokoľvek z toho na úkor zrozumiteľnosti.

[trekker.dk]

Je možné oponovať argumentom, že samotní autori používajú "Smack". Na to sa da spýtať, kde sa vzala verzia napísaná veľkými písmenami v prvej kapitole týchto JN.

A na to se dá odpovědět, že samotný autor v daném místě použil verzi napsanou velkými písmeny. FYI originál JN nepíše jeden člověk, ale dva + nepravidelní přispěvatelé.

Chcem len povedať, že v tak technickom texte ako sú JN musí snaha za každú cenu dodržať pravidlá slovenského/českého jazyka stroskotať.

Sám jsi to napsal - Kde je vôľa, tam je cesta.

[Hynek (Pichi) Vychodil]

Možná by bylo užitečné uvést možné řešení. V nějaké překladatelské příručce jsem našel tuto jednoduchou radu. Jestliže potřebuješ vyskloňovat nějakou zkratku nebo cizí slovo bez běžného překladu, předřaď před zkratku české podstatné jméno a to vyskloňuj. Takže můj návrh zní: ... poskytovanému systémem/subsystémem/komponentou/implementací SELinux nebo Smack.

[cronin]

Možná by bylo užitečné uvést možné řešení.

Prvá veta.

[trekker.dk]

Upřímně doufám, že uznáš, že prostě není v mých silách znát veškerý hardware, který běží pod Linuxem, podle jména.

A pro, ty kdo daný hardware znají, není problém napsat něco jako "audio zařízení v Palm T|X, T5 a LifeDrive", "audio zařízení na desce Marvell Zylonite" s poznámkou, proč to má být takhle. Vypadá to líp než "šmarjá..."

[marbu]

… místo poradních zámků [advisory locks].

Přijde mi, že termín nepovinné zamykání/zámky je výstižnější (a zatím jsem se s jiným překladem nesetkal).

[Robert Krátký]

Dík.

[Filip Jirsák]

Ve čtvrtém citátu pravděpodobně chybí "něm":

jestli v najdeme nějakou hloupou chybu

V síťové vrstvě jsou nyní podporovány algoritmus omezující TCP zácpu CUBIC 2.3 [TCP congestion control algorithm] a vlastnost "zpětné upozornění na zácpu" [backward congestion notification].

Přišlo by mi lepší "...je nyní podporován...", ten přívlastek u algoritmu je dost dlouhý a s tím množným číslem se to špatně čte, člověk pořád hledá, kde už ten přívlastek skončí a bude pokračovat něco dalšího, co je podporováno.

API NAPI bylo trochu pročištěno. konkrétně funkce

Má být velké písmeno po tečce.

Všechno zpracování nyní probíhá v kontextu tvrdého IRQ (hardirq)

Chybí tečka na konci věty.

Se začleněním těchto háčků byla odstraněna jedna hlavní překážka začlenění bezpečnostních modulů jako AppArmor a TOMOYO.

Asi buď "jedna překážka" nebo "jedna z hlavních překážek".

Dvě nové funkce - stop_machine_create() a stop_machine_destroy() - umožňují nezávislé vytváření vláken používané stop_machine()

Nemělo by tam být používaných? Nebo to má význam umožňují funkcí stop_machine() používané nezávislé vytváření vláken?

většinou protože si někdo strávil čas tím

Přebývá "si".

Říct jaderným vývojářům "vezměte tenhle velký kus kódu a hoďte ho do svého jádra, protože když to neděláte, tak si sebereme svůj míček a jdeme domů," není způsob, jakým to tu funguje.

Neděláte -> neuděláte; čárka před ukončující uvozovkou je podle mne nadbytečná.

Asi jsem v poslední době četl nějak hodně textů ke korekturám a zůstalo mi to

[Robert Krátký]

Raděj mi to posílej na e-mail, ať z toho nemám tak blbý pocit

[trekker.dk]

Asi jsem v poslední době četl nějak hodně textů ke korekturám a zůstalo mi to

No co, minule sis stěžoval, že nemáš co opravovat, tak jsme ti tam tentokrát nechali nějaké chyby

Jenom co se týče:

Přišlo by mi lepší "...je nyní podporován..."

Mě ne.