Jaderné noviny – 15. 7. 2009

11. 8. 2009 | Jirka Bourek | Jaderné noviny | 3283×

Aktuální verze jádra: 2.6.31-rc3. Citáty týdne: Ted Ts'o, Andrew Morton, Linus Walleij. V krátkosti: Konference vger.kernel.org; Btrfs a RAID; VFAT; Kmemleak. Sdělování požadavků vývojářům jádra. X bez roota. Nový způsob, jak zkrátit() soubory.

Obsah

• Aktuální verze jádra: 2.6.31-rc3
• Citáty týdne: Ted Ts'o, Andrew Morton, Linus Walleij
• V krátkosti
  • Konference
  • Btrfs a RAID
  • VFAT
  • Kmemleak
• Sdělování požadavků vývojářům jádra
• X bez roota
• Nový způsob, jak zkrátit() soubory

Aktuální verze jádra: 2.6.31-rc3

Současné vývojové jádro 2.6 je 2.6.31-rc3 vydané Linusem 13. července. Je v něm spousta oprav, ale tato předverze také obsahuje nový ovladač pro maticové numerické klávesnice založené na GPIO, ovladač „osdblk“ (který objekt na zařízení pro ukládání objektů prezentuje jako linuxové blokové zařízení), podporu pro nahrávání symbolů jaderných modulů do nástrojů pro čítače výkonnosti a odstranění ovladače pro Intel Langwell USB OTG (protože závisí na infrastruktuře, která v jádře ještě není). Zkrácený changelog je v oznámení; všechny detaily lze nalézt v kompletním changelogu.

V minulém týdnu nevyšly žádné stabilní aktualizace.

Citáty týdne: Ted Ts'o, Andrew Morton, Linus Walleij

Pro mnoho jaderných vývojářů nejsou ty nejstrašidelnější nápady/patche ty, které jsou totálně mimo a praštěné (jako třeba umožnit, aby bylo jádro schopné analyzovat a vykonávat příkazy podobné SQL předané modifikovanému systémovému volání readdir ve vznešené ale donquijotské snaze o sjednocení souborových systémů a databází), ale ty, které jsou dostatečně příčetné na to, aby se zpočátku zdály jako přitažlivé, ale z nichž se stane mlýnský kámen, který extrémně ztěžuje budoucí vývoj a zpětnou kompatibilitu. Přinejmenším mám podezření, že strach z toho často způsobuje nepřátelské přijetí, kterého se některým dostalo (bez ohledu na to, jestli toto přijetí bylo oprávněné, nebo ne).

-- Ted Ts'o

Proto jsou změny vnitřní MM tak obávané – má příliš tajnou a jemnou historii, výkonnostní závislosti jsou poměrně nepřímé a nejsou zjevné a odhalení regresí má dlouhé zpoždění.

-- Andrew Morton

Mít tohle jméno se hodí, lidé moje ovladače revidují jako diví.

-- Linus Walleij (díky Alexandru Riveira Fernándezovi)

V krátkosti

Konference

Zdá se, že vger.kernel.org, ten rušný systém, který obsluhuje většinu mailových konferencí zaměřených na jádro, bude mít nového správce. Nový systém se nazývá „listmanager“; má za cíl být o něco výkonnější než existující instalace majordomo. Rozhraní by nicméně mělo zůstat stejné.

Byla zaslána počáteční verze softwaru pro ty, kdo by si s ním chtěli hrát. Autor kódu Matti Aarnio říká: Někdo bude chtít vědět, jestli budou k dispozici zdrojové kódy. Ano, ale zatím to programuji teprve třetí den…

Btrfs a RAID

Když už mluvíme o softwaru v počátečním stádiu, David Woodhouse zaslal prvotní implementaci podpory RAID5 a RAID6 v Btrfs. Není ještě úplně funkční, ale na místě je už mnoho kousků. Další dobrá zpráva je, že tato práce neznamená přidávání další implementace RAID do jádra; místo toho David přesunul implementaci MD do společného kódu, aby ji bylo možné použít na obou místech.

VFAT

Andrew Tridgell pokračuje v práci na patchi obcházejícím patenty na VFAT (vizte Microsoft vs TomTom). Zařídil adresář na kernel.org, který obsahuje nejnovější verzi patche; také je tam soubor README, který popisuje problémy s interoperabilitou, jež byly zatím identifikovány. Mezitím někteří vývojáři tlačí na návrat předchozí verze patche, která jednoduše odstraňovala schopnost vytvářet dlouhá jména souborů. Tato verze odstraňuje užitečnou funkcionalitu, ale také je u ní poměrně dobře garantováno, že problémy s interoperabilitou nezpůsobí.

Tridge se, jak se zdá, se přístupu s pouze dlouhými jmény nevzdává. Zůstaňte na příjmu; možná ještě přijde s verzí, která s ostatními zařízeními spolupracuje univerzálněji.

Kmemleak

Kód kmemleak byl začleněn do 2.6.31; to znamená, že testeři nyní začínají posílat hlášení o únicích paměti. V tomto stavu se zdá, že kmemleak stále vypisuje slušné množství chybných hlášení – také ale ukazuje skutečné úniky. Lidé, kteří mají zájem si s kmemleak hrát, by měli (1) provozovat 2.6.31-rc3 či novější a (2) podívat se na tyto návrhy pro vyhodnocování hlášení o únicích, které zaslal autor kmemleak Catalin Marinas.

Sdělování požadavků vývojářům jádra

Kernel summit 2009 je plánován na říjen v Tokiu. Během let si Jonathan Corbet, autor tohoto článku, všiml, že diskuze o tom, co diskutovat na summitu, může občas být stejně zajímavá jako summit samotný. Nedávno byla položena otázka, jak mají programátoři v uživatelském prostoru sdělit své potřeby jaderné komunitě. Následná diskuze neobsahovala příliš mnoho definitivních odpovědí, ale problém se začal zajímavým způsobem vyjasňovat.

Zvídaví mohou celé vlákno najít v archivu ksummit-2009-discuss. Matthew Garret věci začal takto:

Právě jsem měl přednášku na desktop summit v Gran Canaria o funkcionalitě, kterou by vývojáři v uživatelském prostoru rádi od jádra. Vyplynulo z toho několik zajímavých věcí, ale jeden z hlavních bodů je, že lidem obecně nebylo jasné, jak tyto potřeby sdělit jaderným vývojářům. Má to cenu diskutovat?

Odpověď Daveho Jonese byla stručná:

V čem přesně je problém? Ví, kde najdou linux-kernel@vger.kernel.org, takže proč s námi nemluví tam?

Pro vývojáře, kteří jsou zvyklí na způsoby linux-kernel a kteří se dlouho pohybují v komunitě, by tato otázka mohla dávat smysl. Když se ale zeptáte vývojářů, kteří se v jaderné komunitě příliš nevyskytují, pravděpodobně dostanete jednu z následujících odpovědí:

1. Na linux-kernel je příliš velký provoz na to, aby se s ním běžní lidé dokázali vyrovnat.

2. I když linux-kernel stíháte, kvůli provozu se tam pravděpodobně to, co pošleme, ztratí.

3. Lidé od jádra mluví svým vlastním jazykem, což ztěžuje sledování diskuze, o účasti v ní ani nemluvě.

4. Pokud si někdo našeho požadavku všimne, pravděpodobně ho uflamuje na škvarek, přičemž někdy si ani nedá tu práci ho pochopit.

5. Pokud se o tom nebude flamovat, pravděpodobně nám řeknou, abychom poslali patch; my ale nejsme jaderní vývojáři, a tudíž není v našich silách to udělat.

Není pochyb o tom, že některé z problémů při komunikaci lze snadno svalit na stranu toho, kdo o něco žádá. Pokud je žádost o vlastnost formulována jako požadavek, pravděpodobně nebude dobře přijata. Jaderní vývojáři musí plnit požadavky svých zaměstnavatelů, ale nikoho jiného; jako většina vývojářů se přitom dívají úkosem na ty, kdo mají pocit, že mají nárok na práci zadarmo, prostě protože chtějí. Klasickým příkladem by zde byly specifikace Carrier Grade Linux, které vytvořila OSDL; čtou se jako seznam věcí, které má jaderná komunita k vyřízení, i když OSDL nakonec tvrdila, že tak to myšleno nebylo.

Další problém mohou být špatně vyjádřené potřeby. Vezměme v úvahu počáteční návrh TALPA, kde byla zaslána velmi jasná sada nízkoúrovňových požadavků. Bohužel byly příliš nízkoúrovňové, vyžadovaly vlastnosti jako schopnost zachytit operaci zavření souboru. Místo toho TALPA (nyní fanotify) mělo vyjádřit potřeby jako „potřebujeme čistý způsob, kterým podporovat proprietární software pro vyhledávání malwaru a zde jsou důvody“. Toto neporozumění projekt významně zbrzdilo a mohlo by snadno zlikvidovat projekt, jehož vývojáři by měli méně vytrvalosti nebo méně ochoty se učit. Jasné vyjádření požadavků nikdy není jednoduchý úkol, ale je to nezbytně nutné.

A nakonec některé nápady prostě v jádře nedávají smysl. Nemusí být možné je implementovat takovým způsobem, který by se vyhnul bezpečnostním problémům, který by nerozbil další vlastnosti a který by nevytvořil dlouhodobé problémy s údržbou. Nebo jsou lepší řešení v uživatelském prostoru. Programátor, který na linux-kernel přijde s takovýmto požadavkem, pravděpodobně odejde s pocitem, že jsou jaderní vývojáři naprosto neochotní diskutovat.

Nehledě na to bylo uznáno, že vývojáři v uživatelském prostoru mají skutečné problémy s tím předat své požadavky jaderné komunitě. Jaderní vývojáři bývají zaneprázdnění, zaměření na své vlastní projekty a ne vždy zcela otevření požadavkům, které vznikly mimo komunitu. Neexistuje mechanismus pro sledování žádostí o vlastnost [feature request], takže se snadno stane, že jsou požadavky záplavou e-mailů pohřbeny. Tón diskuze může být nepříjemný, i když to se během let skutečně zlepšilo. A tak dál.

To není dobře. Jádro je tu proto, aby uspokojovalo potřeby uživatelského prostoru; pokud jaderná komunita neslyší, jaké potřeby to jsou, nemůže jinak než selhat při jejich uspokojení. Zdá se tedy, že by stálo za to přemýšlet o tom, jak vývojářům v uživatelském prostoru zjednodušit komunikaci s jadernými vývojáři; je zde určitá šance, že tomu na summitu bude vyhrazen prostor. S diskusí o tom, jak by se stav dal zlepšit, nicméně není potřeba čekat na summit.

Matthew Wilcox navrhl vytvoření dokumentu o tom, jak mají vývojáři v uživatelském prostoru komunikovat s jadernou komunitou. Tento nápad dává smysl (a autor tohoto článku, Jonathan Corbet, by se mohl pokusit v tomto bodě pomoci), ale zde se nejedná o problémy, který lze vyřešit jenom dokumenty.

James Bottomley popsal tři široké kategorie uživatelů, kteří potřebují změny v jádře:

1. Pokročilí vývojáři, kteří si rozšíření do jádra mohou napsat sami.

2. Uživatelé, kteří jsou schopni zaujmout jaderného vývojáře, aby jimi požadovaný přídavek napsal.

3. Uživatelé, kteří chtějí vlastnosti, které žádného z vývojářů nezajímají.

James poukazuje na to, že kategoriím 1 a 2 lze pomoci dokumentací. Má ale obavy, že nemáme možnost, jak pomoci třetí kategorii uživatelů, kterým nezbývá jiný způsob, jak dostat do jádra změny, které vyhovují jejich potřebám.

Ted Ts'o má jiné třídění, které předložil ve snaze pomoci s pochopením problému.

1. Hlavní jaderní vývojáři (nebo lidé, kteří mají k těmto lidem přístup). Hlavní vývojáři mají výhodu v tom, že jim komunita značně důvěřuje; to jim umožňuje dostat do jádra vlastnosti s relativně malými problémy. Jsou schopni začlenit kód, který by nevyhověl, pokud by přišel z jiného zdroje.

2. Kompetentní, ale ne hlavní vývojáři jádra (a – opět – lidé, kteří k nim mají přístup). Tito vývojáři musí pracovat tvrději, aby své změny ospravedlnili, ale obecně jsou v postavení, ve kterém mohou svoji práci začlenit, pokud je dobrá.

3. Potenciálně kompetentní vývojáři „známí mizerným navrhovacím vkusem“. Ted naznačil, že skutečným účelem revidovacího procesu jádra je hlavně probrat patche z tohoto zdroje.

4. Uživatelé bez přístupu k vývoji jádra, kteří tedy musí v komunitě přesvědčit někoho jiného, aby pro ně potřebnou vlastnost implementoval. Ted tuto kategorii rozdělil na dvě podkategorie podle toho, jestli v oblasti zájmu uživatele pracuje nějaký aktivní vývojář, nebo ne.

Ted si myslí, že toto roztřídění může uživatelům pomoci pochopit, proč jsou některé patche a nápady posuzovány tak, jak jsou. Také by mohlo být možné jej použít při vývoji způsobů, jak komunikovat s jednotlivými skupinami uživatelů – je jisté, že různé skupiny potřebují slyšet různé zprávy. Lze tvrdit, že existující dokumentace by měla být dostatečná pro lidi se zkušenostmi s vývojem jádra, ale lidem, kteří potřebují najít vývojáře, který by za ně udělal nějakou práci, se pomoci nedostává.

Jde o tu poslední skupinu, která bude nejpravděpodobněji zastrašena vyhlídkou na to, že bude muset přijít na linux-kernel a prosit o nové funkce. Jaderná komunita by opravdu měla využití pro osobu, která by se zhostila úkolu pracovat s těmito uživateli, pomoci jim objasnit své potřeby, zkontaktovat je se správnými vývojáři a sledovat požadavky. Dobrá zpráva je, že takovou osobu máme; špatná je, že je to Andrew Morton, který má na práci ještě pár dalších drobností. Komunitě by prospěla osoba, která by v podstatě na plný úvazek pomáhala uživatelům a vývojářům v uživatelském prostoru dostat od jádra to, co potřebují. Takové místo nicméně bývá velmi obtížné financovat, a tím pádem zůstává volné.

Jak bylo zmíněno na začátku, výsledkem této konverzace nebylo mnoho konkrétních závěrů. Zdaleka ale nebylo uzavřena; pokud ne dříve, bude obnovena v říjnu na summitu. Není potřeba říkat, že Jonathan má v úmyslu u toho být; zůstaňte na příjmu.

X bez roota

Složitost je dlouho známým nepřítelem bezpečnosti. U kódové základny, která je malá a přímočará, lze s rozumným stupněm důvěryhodnosti snadno ověřit, že dělá to, co má dělat, a nic víc. Čím více je kód složitý a obtížně pochopitelný, tím více je toto ověřování složité. Z tohoto důvodu se vývojáři snaží oddělit kód, který privilegia potřebuje, od kódu, který je nepotřebuje. Jakýkoliv kód, který běží v neprivilegovaném režimu, je kód, který pravděpodobně nezpůsobí bezpečnostní problémy; zbytek lze – snad – revidovat na úrovni dostatečné k tomu, aby to poskytlo potřebný stupeň důvěry v jeho bezpečnost.

Nyní vezměme v úvahu X Window System. To je masivní kus kódu, který má relativně malou vývojovou komunitu. Část tohoto kódu je pradávná a mnoho pozornosti vývojářů se jí za poslední léta nedostalo. Jako u většiny projektů je kvalita části kódu vyšší než zbytku. X server provádí složitý úkol – založený na komplikovaném protokolu – pro téměř každého uživatele Linuxu. Občas je dokonce vystaven celému internetu. A přitom běží pod rootem se všemi oprávněními. Skutečný počet problémů nalezených v X byl během let poměrně malý, ale těžko nevěřit tomu, že jde víc o štěstí a nedostatek útočníků než o kvalitu kódu X.

Tyto obavy nejsou u X serveru nové; proto se léta diskutuje o tom provozovat jej v neprivilegovaném režimu. Mnoho z práce odvedené na grafice se týkalo tohoto cíle. I přesto linuxové distribuce stále instalují X jako setuid program – zatím prostě nebylo možné dát neprivilegovanému X serveru šanci dělat svou práci bez toho, aby se otevřel systém jako celek.

Tyto dny jsou v podstatě u konce. Projekt Moblin nyní tvrdí, že bude první distribucí, která bude dodávat neprivilegovaný X server. A kam půjde Moblin, tam ho určitě budou následovat ostatní.

Nějaké detaily, jak byla tato práce udělána, zaslal Jesse Barnes do e-mailové konference xorg-devel. Podle něj bylo dokončení tohoto několikaletého úkolu „poměrně snadné“. Zdá se, že všechny kousky jsou již na místě – přinejmenším pro některý grafický hardware – do té míry, že pár hodin práce stačilo k dokončení. Zdá se to jako téměř nedůstojně nevypjatý závěr pro takto dlouho existující výzvu, nicméně práce, která tento výsledek umožnila, samozřejmě trvala dlouhou dobu.

Největším kouskem je kód pro jaderné nastavování režimu [kernel mode setting, KMS], který byl začleněn do 2.6.29. Před KMS byl X.org server pověřen tím, že musel najít hardware a z uživatelského prostoru ho správně řídit. Není potřeba říkat, že tento přístup by být mohl snadno zneužit k ohrožení celého systému, proto je k němu potřeba oprávnění superuživatele. KMS (a s tím spojený kód správy grafické paměti) mění grafický hardware na něco, co je bližší běžnému zařízení s běžným jaderným ovladačem – i když jde o poněkud složitý a specializovaný druh „běžného“ zařízení. Manipulace s hardwarem, které vyžadují vyšší oprávnění, byly izolovány v relativně malém kousku jaderného kódu; nyní jsou oddělené od toho velkého tělesa kódu, které implementuje protokol X.

To znamená, že kód X přistupující k hardwaru nyní může běžet bez zvýšených oprávnění, pokud bude mít možnost otevřít odpovídající soubor zařízení. Server také musí mít možnost otevřít další soubory zařízení: Vstupní zařízení, virtuální konzoli a tak dál. Tento problém byl ale vyřešen již před lety; proces login může snadno změnit vlastníka těchto souborů, takže neprivilegovaný server k nim bude moci přistupovat, ale zbytek světa ne.

Zbývají nějaké detaily. Některá volání ioctl() pro přímé vykreslování jsou nyní pouze pro roota; Jesse si myslí, že je možné je změnit tak, aby byla bezpečně dostupná každému. Možná budou nějaké malé přídavky do ABI ovladačů, aby se poslední operace pouze pro roota přesunuly do jádra. To je ale v podstatě všechno.

X v uživatelském režimu budou samozřejmě fungovat jenom s čipy od Intelu, protože jedině ty mají nyní plnou podporu KMS. Ovladače Radeon tuto podporu nicméně získávají rychle a v relativně krátkém čase by měly být schopné podporovat práci bez roota také. Z velké trojky tak jako obvykle stojí mimo jenom čipset NVIDIA; současná matice vlastností Nouveau naznačuje, že bude ještě nějaký čas trvat, než budou k dispozici potřebné vlastnosti.

Také možná bude nějakou chvíli trvat, než podporu práce bez roota uvidíme v obecnějších distribucích. Moblin je relativně úzce zaměřen na hardware od Intelu, což souvisí s faktem, že jsou to stále většinou lidé od Intelu, kteří na něm pracují. Distributoři, kteří potřebují, aby věci fungovaly na jakémkoliv přítomném hardwaru, mohou ke změně tohoto rozsahu přistupovat s o trochu větší opatrností. X bez roota jsou nicméně budoucností a ta budoucnost je blízko.

Nový způsob, jak zkrátit() soubory

Originál tohoto článku pro LWN.net napsal Goldwyn Rodrigues.

Ve způsobu, jakým spolupracují subsystémy virtuálního souborového systému a virtuální paměti, se dějí změny. Jedním z cílů této práce je odstranit souběh existující v page_mkwrite() (volána, když se záznam v tabulce stránek [page table entry, PTE] má ze stavu pouze pro čtení změnit na zapisovatelný), konkrétně zajistit, že budou bloky souboru správně vyplněny nulami po operaci truncate, která soubor zvětšuje. Jako součást vylepšení page_mkwrite() zaslal Jan Kára sadu patchů. Tyto patche nicméně zavedly jako řešení problému nový zámek a Nick Piggin si myslí, že problém lze řešit pomocí zámku stránky a nový zámek že není potřeba. Jako první krok směrem k řešení problému zaslal sadu patchů, které vylepšují sekvenci zkracování. Nové sekvenci lze snáze porozumět, její používání je flexibilnější a, což je nejdůležitější, jsou v ní lépe ošetřeny chyby.

Systémová volání truncate() a ftruncate() se používají k nastavení velikosti souboru na specifikovanou hodnotu. Pokud je soubor větší než předaný parametr, je zmenšen a část, která přesahuje danou velikost, je ztracena. Pokud je současná velikost souboru menší než předaný parametr, soubor se zvětší a oblast větší než původní velikost je vyplněna nulami. Parametr velikosti nemůže být větší, než je maximální možná velikost souborového systému.

Volání truncate() z uživatelského prostoru je v jádře obsluhováno do_sys_truncate(), která zodpovídá za vypletí všech chyb (jako „inode je adresář“ či chyby oprávnění). Zlikviduje pronajmutí [leases] souborů zamčených pomocí flock() a zavolá do_truncate(). do_truncate() následně vytvoří novou strukturu atributů s novou délkou souboru a zavolá notify_change() s dentry a novými atributy pod inode->i_mutex.notify_change() volá obecnou inode_setattr() buď přímo, nebo přes implementaci setattr() souborového systému. inode_setattr() poté volá vmtruncate(), která nastaví velikost inodu a odmapuje stránky mapované za novou velikostí souboru. Po odmapování stránek je zavolána operace truncate() odpovídajícího souborového systému, aby se uvolnily diskové bloky spojené se souborem.

Podle Nicka má tento přístup nedostatky:

Velký problém předchozí sekvence volání: Souborový systém není volán předtím, než se změní i_size. To znamená, že není dovoleno, aby volání selhalo, a to také neví, jaká byla předchozí i_size. Obecný kód volající vmtruncate ke zkrácení alokovaných bloků také nemá žádnou možnost, jak vrátit smysluplnou chybu (nebo například atomicky vyřešit dealokaci bloku).

Nickova nová sekvence zkracování zavádí způsob, kterým lépe sdělovat chybové stavy, a konsoliduje testy, které většina souborových systémů nyní provádí individuálně. Původním záměrem bylo přidat do struct inode_operations novou operaci truncate(), která by byla v inode_setattr() volána přímo. Christoph Hellwig nesouhlasil s tím, že by měla být nová zkracovací funkce volána z notify_sequence a ne z inode_setattr, která je výchozí implementací inode_operations.setattr. Nick měl pocit, že vynulování ATTR_SIZE před voláním obecného setattr není neobvyklé (diskutováno níže), takže se rozhodl zavést své změny příznakem nazvaným new_truncate v struct inode_operations a novou zkracovací funkci vůbec nepoužít. Příznak new_truncate indikuje, že funkce truncate() v operacích inode zvládá nový formát. Nick přiznává, že zavádění proměnné do inode_operations je ošklivý hack, bude však zapotřebí do doby, než všechny souborové systémy přejdou na novou sekvenci zkracování. Kód souborového systému, který neimplementuje novou konvenci, automaticky inicializuje new_truncate() na nulu, čímž dá najevo, že se ještě nezměnil.

První patch ze série zavádí nové funkce, které změnu podporují. inode_newsize_ok() provede jednoduché kontroly toho, jestli je nová velikost souboru v mezích velikosti definované souborovým systémem a jestli to není swapovací soubor:

int inode_newsize_ok(struct inode *inode, loff_t offset)

Tyto kontroly jsou v současnosti prováděny jednotlivými souborovými systémy. Použití této funkce povede k pročištěním v kódu souborových systémů.

Funkce truncate_pagecage() zkrátí stránky inodu a odmapuje stránky, které jsou v rozsahu za novou velikostí souboru:

void truncate_pagecache(struct inode *inode, loff_t old, loff_t new);

truncate_pagecage() by ideálně měla být volána předtím, než souborový systém uvolní datové bloky spojené s inodem. Tak by cache stránek byla vždy synchronní s formátem na disku a souborový systém by nemusel řešit situace jako volání writepage() pro stránku, jejíž bloky byly dealokovány.

Funkce vmtruncate() je konzolidována pro NUMA a ne-NUMA architektury v mm/truncate.c. vmtruncate() je však zastaralá, místo ní by se měly používat truncate_pagecache() a inode_newsize_ok() zavedené prvním patchem.

Třetí patch je hlavním patchem série, která používá nové operace zkracování. Zavádí simple_setsize(), která provádí ekvivalent vmtruncate(). simple_setsize() je volána z inode_setattr(), kde je předáno ATTR_SIZE. Souborové systémy, které implementují vlastní kód pro zkracování, musí tedy ATTR_SIZE vynulovat předtím, než zavolají obecné inode_setattr().

Aby implementovaly nové standardy zkracovací operace, musí jednotlivé souborové systémy implementovat vlastní funkcí setsize(), která provede kontroly správnosti velikosti souboru, zkrátí cache stránek a zkrátí datové bloky spojené s inode. Souborové systémy nesmí zkrátit bloky za i_size použitím vmtruncate(), místo toho musí řešit zkrácení v kódu souborového systému použitím truncate_pages(). To vytváří lepší prostředí pro zachytávání chyb. Pole inode_operations.new_truncate a inode_operations.truncate zmizí poté, co budou konvertovány všechny souborové systémy.

Aby se tato změna demonstrovala, poslední patch v sérii mění souborový systém ext2 tak, aby používal nové rozhraní pro zkracování. Patch zavádí ext_setsize(), která nastavuje velikost inodu pro soubor, zkrátí cache stránek a nakonec zkrátí datové bloky na souborovém systému. Když je nastaveno ATTR_SIZE, ext2_setattr() volá k provedení zkrácení ext2_setsize() a ATTR_SIZE je vynulováno, aby inode_setattr() operace neprovedla znovu.

Nová sada patchů pro zkracování prošla slušnou porcí revizí a pravděpodobně bude začleněna. Než ale všechny souborové systémy přejdou na nový způsob zkracování souborů, bude zapotřebí „ošklivý hack“; ten bude nakonec odstraněn. Patche jsou součástí zlepšení, které by Nick rád dostal do vrstvy VM. Na základě nových patchů zkracování Nick zaslal RFC ohledně toho, jak by chtěl zlikvidovat souběh v page_mkwrite(), když je soubor zkrácen za současnou velikost. Odstraňování souběhů v jádře je dobrá věc, takže očekávejme, že bude tato práce pokračovat slušným tempem.

       

Komentáře

[Mandarinka]

"revidují jako blázniví"  ---- čeština má myslím v úzu spíše spojení "revidují jako diví". Bláznivý mi zní nepřirozeně...

komentář prosím zvažte a smažte :)

[Robert Krátký]

Díky, to zní lépe.

[Jan Drábek]

Perfektní počtení

[Marex]

'nový ovladač pro maticové numerické klávesnice založené na GPIO' ... tohle je preklad 'matrix keypad' ? Kde je tam napsane, ze to je numericka klavesnice (je tam generic, ne numeric )  ? Co treba 'maticove klavesnice rizene GPIO piny' ?

[trekker.dk]

keypad není klávesnice - ve většině případů nemá většinu písmen (respektive většinou má jenom čísla a enter - proto píšu numerické)

[Marex]

Vyhledej si 'palm tungsten C' a podivej se jak tam ten keypad vypada (je to to pod LCD)

[petr_p]

Na základě jednoho pomýleného použití nelze měnit význam slova. Mimochodem, kdo tomu říká keypad? Palm?

[Marex]

Nejspis tomu rika keypad autor toho driveru.

[knizmi]

Fungují někomu rc verze 2.6.31 s wifi kartou iwl3945? U mě se karta neustále připojuje a odpojuje.

[Ahmul]

Taky jsem zaznamenal nějaké regrese, ale u jiného čipu. Snad to chlapci odladí než vyjde vanilla:)

[Mrkva]

Tady uzivatel iwl3945 a jadro 2.6.31-rc5. Vsechno funguje bez problemu. V dmesgu je jediny reAssoc (po suspendu). Ale je moznost, ze to drzi bezici wicd resp. wpa_supplicant :)

[knizmi]

Jo, wpa_supplicant mi bezi, zkusim to nekde na nesifrovane siti. Diky za info.

[knizmi]

Pokud tuto diskusi ještě někdo s iwl3945 sleduje, používáte hw nebo sw scannování sítě? Právě jsem zjistil, že problém je právě při scannování, což wicd i nm dělají docela často. Sw scannování přeruší asi na 1s spojení, ale zůstanu připojený, zatímco hw scan mě rovnou od AP odpojí. Zatím jsem to vyřešil tak, že modul iwl3945 načítám s parametrem disable_hw_scan=1, ale není to ideální řešení.

[Nicky726]

Přináší KMS a provoz X pod uživatelem kromě vyšší bezpečnosti ještě něco dalšího? Já jen, zda to má cenu zkoušet rozchodit, pokud s tím distribuce nepočítá...

[thingie]

KMS toho potenciálně přináší v linuxové grafice strašně moc, možnost mít Xka pod uživatelem je jenom jedna nevýznamná z nich.

[Nicky726]

A reálně?

[thingie]

No, například to dovoluje mít i v Linuxu BSOD :)

[trekker.dk]

Například to jádru dává možnost přepnout se zpátky do textového režimu, což se hodí, když je potřeba vypsat něco důležitého - například výpis u kernel panic, oops atd.; v současnosti když se jádro takhle sekne, tak se nemáš šanci dozvědět proč, pokud náhodou nezafunguje některá z kouzelných klávesových zkratek (vlastní zkušenost: většinou nezafunguje ani jedna)

[Josef Kufner]

Teď je ještě otázkou, zda jádro opravdu do toho textového režimu přepne...

Btw, netušíte někdo od jakých verzí je KMS plánované/implementované tak, že to bude normálně použitelné?

[trekker.dk]

To teď AFAIK v podstatě záleží na X severu, použitelné by to být mělo (samozřejmě na podporovaném HW, tj. s kartami Intel)

[thingie]

Na Fedoře 11 s i945 a 2.6.30 se dá KMS označit za v podstatě normálně použitelné.

[geebranz]

Skilled developers polebarnswichitaks.com