Jaderné noviny 263

Opravy a aktualizace ReiserFS verze 3. Podpora tabulky atributů stránek v 2.6. SATA bude ve 2.4.27. Automatický hledač chyb odhalil v jádře několik děr. Dokumentace ke kompilaci externích modulů.

Do konference přišlo celkem 3414 emailů, nejvíce jich poslali Andrew Morton, Greg KH a Dmitry Torokhov.

Opravy a aktualizace ReiserFS verze 3, 22 e-mailů

Sadu experimentálních patchů pro reiserfs v3 můžete stahovat odsud:

ftp://ftp.suse.com/pub/people/mason/patches/reiserfs/2.6.5

Vzhledem k tomu, že některé z těchto již v -mm jsou a jiné ne, jsou připraveny dva soubory: series.linus obsahuje patche potřebné pro hlavní strom 2.6.5, series.mm pak patche pro 2.6.5-mm1.

Většina je od Jeffa Mahoneyho a ode mě. Jsou mezi nimi:

opravy chyb
optimalizace logování
podpora data=ordered
xattr
acl
kvóty
chybové hlášky s názvy zařízení (založeno na Olegově patchi pro 2.4)
vylepšení alokátoru bloků

ACL a xattr od Jeffa Mahoneyho pro reiserfs v3 už jsou nějakou dobu používány v 2.4 a 2.6 kernelech od SUSE. Mnohokrát jsem je poslal do namesys ke kontrole, ale Hans ten kód vůbec nechce vzít na vědomí. Minulý měsíc jsem se znovu pokusil s ním o tom kódu mluvit, ale úplně mě ignoruje.

Jeho tehdejším argumentem bylo, že nechce nové funkce ve verzi 3. Ta implementace ale nikterak nezmění formát disku (xattr jsou uloženy jako běžné soubory ve skrytém adresáři). Mám zato, že reiserfs tyto funkce potřebuje, aby byl v jádře i nadále aktuální, a proto je posílám k začlenění do -mm. Pro -mm sérii Andrewovi posílám následující patche ze series.mm:

reiserfs-end-trans-bkl
reiserfs-acl-mknod.diff
reiserfs-xattrs-04
reiserfs-acl-02
reiserfs-trusted-02
reiserfs-selinux-02
reiserfs-xattr-locking-02
reiserfs-quota
permission-reiserfs
reiserfs-warning

(což znamená vše kromě kódu nového alokátoru bloků)

Následovala kratší diskuze ohledně alokátoru bloků a problémech, se kterými se současná i nová implementace potýká. O něco dále nabídl Chris Wright patch, ale Chris Mason odpověděl: Na počátek patche budeš muset přidat pár slov o tom, že Hansovi přenecháváš copyright. Ale Hans Reiser reagoval s tím, že taková formulace je velmi nepřesná. Tento dokument: www.namesys.com/legalese.html to vysvětluje lépe. Budeš-li tak laskav a povolíš mi licencovat příspěvek do reiserfs třetím stranám (kromě běžné GPL), budu za to rád, protože mi to občas umožňuje získat velmi potřebné prostředky pro vývoj reiser4.

Podpora tabulky atributů stránek v 2.6, 20 e-mailů

Před dost dlouhou dobou jsem poslal email o přidání podpory tabulky atributů stránek (PAT - Page Attribute Table) (http://www.kerneltraffic.org/kernel-traffic/kt20030616_219.html#3).

Tehdy šlo o to, abychom měli možnost označit remapované I/O stránky jako Write Combined v případě, že by pro ten účel došly MTRR. To bylo především kvůli apertuře AGP a framebufferu. Jak se objevují PCI Express systémy, potřeby se trochu mění. PCI Express nemá centralizovanou aperturu jako AGP, kterou by bylo možno označit WC. Namísto toho musí být jednotlivé systémové stránky paměti označeny WC přes PAT v tabulkách stránek. To výrazně zvyšuje potřebu podpory PAT, aby byla zachována vysoká úroveň výkonu na PCI Express systémech.

Měl jsem pocit, že nejlepší bude se trochu věnovat původním reakcím ještě než se obrátím zpět na LKML. Mluvil jsem o tom s Andi Kleenem, který navrhl, abych se nejprve zaměřil na jednodušší oblasti I/O a pak se vrátil k hlavní paměti po té, co to bude hotovo a budu mít od lidí reakce.

Pracoval jsem na mechanismu (cachemap), který sleduje, jaký druh kešování je pro určitou oblast paměti právě namapován. Při namapování nové oblasti paměti se zeptáme cachemap, jestli je druh kešování nové oblasti stejný jako starý druh (nebo je s ním kompatibilní). Uspěje-li dotaz na cachemap, může být nová I/O oblast bezpečně namapována, jinak ne.

Nejdříve jsem se soustředil na ioremap, aby byly dotazy na cachemap prováděny pouze z ioremap. Také jsem přidal kód, který nechává MTRR kód volat kód cachemap (v tomto případě jde spíše o zprávu než o dotaz - značí, že mapování už bylo provedeno). Provedl jsem několik testů na systémech, které tu mám k dispozici, a všechno se zdá fungovat docela dobře.

Ten současný patch obsahuje původní podporu PAT a ten nový mechanismus cachemap. Upozorňuji, že cachemap mechanismus ve skutečnosti žádné atributy kešování nemění - pouze atributy sleduje a testuje oblasti. Myslím, že finální podoba by mohla být taková, že ovladače by používaly běžné mechanismy ioremap/change_page_attr/remap_page_range jako doposud a tyto mechanismy by používaly cachemap, aby bylo jisté, že nemáme žádné konflikty. Vítám všechny připomínky k tomu, jak by jednotlivé detaily měly fungovat, a jaké je třeba provést změny.

Andi Kleen napsal, že Terencova práce vypadá pro začátek dobře a bylo by dobré to testovat. I tak je však nutné všechno pročistit. Pak dodal:

Co se rozhraní týče, stále si myslím, že by bylo čistší to prostě volat z change_page_attr(). Pak by další uživatelé museli volat jen jednu jedinou funkci. Ale to se dá snadno změnit.

Aby to bylo opravdu užitečné, myslím, že bychom potřebovali ioremap_wrcomb() a podporu ve funkci bus/pci mmap (PCI vrstva už pro tohle má ioctl, pouze to na i386 ignorovali). Pak by to mohl začít využívat X server.

Bez uživatelů asi nebude testování moc dobré, ale než to bude začleněno, musí se tomu nějakého skutečného testování dostat. Možná by to mohlo být prostě pověšeno na nějaký AGP a DRM ovladač. Pak by to lidi aspoň začali testovat.

Eric W. Biederman ještě diskutoval s Andim o přínosu, který by to mělo pro systémy s velkým objemem paměti, zatímco Terence posílal aktualizované patche.

SATA bude ve 2.4.27, 27 e-mailů

Serial ATA, ačkoliv relativně nové, jde kupředu velmi rychle. Tento týden Marcelo Tosatti napsal:

Jeff Garzik mi poslal aktualizované SATA pro začlenění do 2.4.x.

Hodně nových počítačů už se prodává pouze se SATA disky a bylo by dost špatné mít "stabilní" sérii bez podpory takového rozšířeného standardu.

Tohle bude poslední funkce přidaná do 2.4.x - a to pouze proto, že je nezbytná.

Někdo proti?

Stefan Smietanowski řekl, že je to tak dobře, protože 2.4 bude lidmi i nadále používán, zatímco 2.6 se bude stabilizovat a stávat standardem.

Na jiném místě Andre Hedrick Marcelovi spílal za to, že měl SATA začlenit již dávno. Marcelo odpověděl: Jeff poslal SATA 1.0 již dříve, ale radši jsem to ještě chvíli pozdržel (abych si byl jistý, že je to stabilní). Teď to vypadá, že Jeff už v to má důvěru. Následovalo další obviňování, dokud vlákno nevymizelo. Marcelova rozhodnutí ohledně 2.4 budou zjevně kontroverzní až do chvíle, než se plně přejde na 2.6.

Automatický hledač chyb odhalil v jádře několik děr, 19 e-mailů

Ken Ashcraft poslal dlouhý seznam potenciálních chyb v jádře. Doprovodil to vysvětlením:

Pracuji ve společnosti, která se jmenuje Coverity. Děláme na derivátu MC Checkeru vytvořeném ve Stanfordu pro profesionální nasazení. Napsal jsem statický analytický checker, který v jádře vyhledává místa, kde kernel dostane od uživatele skalár a pak jej použije bez provedení kontroly hranic. Například když ovladač načte integer od uživatele a pak ten integer použije jako index pole nebo parametr délky pro mempcy, uživatel může způsobit přetečení bufferu.

Přiložené chyby jsou zhruba seřazeny podle závažnosti. Posledních 12 chyb je celkem nicotných, protože jsou buď chráněny kontrolou capable() nebo jde pouze o 8-bitový skalár. Za malou chybu považuji i předání nezkontrolované hodnoty do kmalloc(). Uvědomuji si, že kmalloc() selže, bude-li požádán o více než 128k, ale i tak možná není vhodné nechávat uživatele alokovat tolik paměti. Všechny tyto chyby jsou ve zprávě označeny [MINOR] a/nebo [CAPABLE].

Chris Wright několik chyb potvrdil a poslal patche; některé šly přes Jeffa Garzika rovnou do 2.4 a 2.6 kernelů, jiné byly nejprve upraveny lidmi jako Andrea Arcangeli. Několik dalších chyb také Chris před ukončením vlákna vyvrátil.

Dokumentace ke kompilaci externích modulů, 4 e-maily

Sam Ravnborg poslal hrubé a nekompletní HOWTO ke kompilaci externích modulů:

Kompilace externích modulů

kbuild poskytuje možnost kompilovat externí moduly za předpokladu, že existuje již zkompilované jádro s plnými zdrojovými kódy. Některé z cílů dostupných pro kompilaci jádra jsou k dispozici při kompilaci externího modulu.

Kompilace modulu

Příkaz vypadá takto:

make -C <path to kernel src> M=$PWD

Aby byl zmíněný příkaz úspěšný, musel být kernel zkompilován s povolenými moduly.

Právě kompilované moduly nainstalujete pomocí:

make -C <path to kernel src> M=$PWD modules_install

Další komplexnější příklady přijdou později. Uvedené příkazy by měly stačit ve většině případů.

Dostupné cíle:

make -C $KDIR M=$PWD

Stejné i při zadání 'modules'. Viz popis cíle modules níže.

make -C $KDIR M=$PWD modules

Zkompiluje moduly umístěné v aktuálním adresáři. Všechny výstupní soubory budou ve stejném adresáři jako zdrojový kód modulů. Neprovádí se žádný pokus o aktualizaci zdrojů jádra a předpokládá se, že make kernelu proběhl úspěšně.

make -C $KDIR M=$PWD modules_install

Instalace externích modulů

make -C $KDIR M=$PWD clean

Odstranění všech vygenerovaných souborů v aktuálním adresáři

Dostupné volby:

make -C $KDIR

Používá se k zadání místa, kde hledat zdrojáky jádra. '$KDIR' představuje adresář se zdrojovými kódy kernelu. Make do zadaného adresáře při spuštění přepne.

make -C $KDIR M=$PWD

M= se používá k oznámení kbuildu, že kompilujeme externí modul. Hodnota parametru M= je adresář, kde je externí modul umístěn. Při kompilaci externího modulu je k dispozici pouze omezená sada obvyklých cílů.

make -C $KDIR SUBDIRS=$PWD

Totéž co M=. SUBDIRS= je ponecháno kvůli zpětné kompatibilitě.

make -C $KDIR M=$PWD help

help vypíše dostupné cíle při kompilaci externího modulu.

Pokročilejší příklad

Tento příklad znázorňuje případ, kdy se distribuce moudře rozhodla oddělit zdrojové kódy jádra a výstupní soubory:

Zdrojové kódy jádra:
/usr/src/linux-<kernel-version>/

Výstup kompilace jádra, včetně .config:
/lib/modules/linux-<kernel-version>/build/

Externí moduly, které chceme kompilovat:
/home/user/module/src/

Moduly umístěné ve zmíněném adresáři zkompilujete následujícím příkazem:

cd /home/user/module/src
make -C /usr/src/linux-<kernel-version> \
O=/lib/modules/linux-<kernel-version>/build \
M=$PWD

Pak je nainstalujte pomocí příkazu:

make -C /usr/src/linux-<kernel-version> \
O=/lib/modules/linux-<kernel-version>/build \
M=$PWD modules_install

Výše jsou uvedeny poněkud dlouhé příkazy a následující část ukazuje, jak to všechno zjednodušit.

Triky pro zjednodušení

.... Tohle je potřeba přepracovat ....

Příkazová řádka s make a několika parametry je únavně dlouhá a náchylná k chybám. Následuje malý trik, který umožňuje kompilaci modulu s použitím jediného příkazu 'make'.

Vytvořte makefile pojmenovaný 'Makefile' s následujícím obsahem:

---> Makefile:

all:
        $(MAKE) -C /home/sam/src/kernel/v2.6 M=$(PWD) \
                        $(filter-out all,$(MAKECMDGOALS))

obj-m := module.o

---> Konec Makefile

Při spuštění si make všimne pravidla all: a zavolá make znovu se správnými parametry.

Je-li vyvíjen ovladač, který má za cíl začlenění do hlavního jádra, je lepší vložit pravidlo all: do Makefile pojmenovaného +makefile (menší velké m) - asi takto:

---> makefile

all:
        $(MAKE) -f Makefile -C /home/sam/src/kernel/v2.6 \
                M=$(PWD) $(MAKECMDGOALS)

---> Konec makefile

Makefile pro kbuild bude obsahovat jedinou věc:

---> Makefile:

obj-m := module.o

---> Konec Makefile

Při spuštění bude make hledat makefile pojmenovaný makefile před souborem pojmenovaným Makefile. Takže make použije soubor s menším velkým 'm'.

Příprava jádra pro kompilaci externích modulů

Při kompilaci externích modulů se očekává, že je na to jádro připraveno. To zahrnuje přítomnost určitých binárek, konfiguraci jádra a symlink na include/asm. K tomuto účelu slouží pohodlný cíl:

make modules_prepare

U typické distribuce by to vypadalo asi takto:

make modules_prepare O=/lib/modules/linux-<kernel version>/build

ZBÝVÁ UDĚLAT: Naplnit následující kapitoly

Verze modulů

Lokální include soubory

CLFAGS := include ...

Pouze binární .o soubory

Používejte _shipped ...