Jak velí tradice, nejprve výpis základního adresáře /proc. Tečka před názvem znamená, že už to máme za sebou:
.840 .devices .kcore modules stat ide/ .842 .dma .kmsg mounts swaps irq/ .847 .execdomains .ksyms mtrr uptime net/ .848 .filesystems .loadavg partitions version nv/ .apm .interrupts .locks pci bus/ sys/ .cmdline .iomem .meminfo self@ driver/ sysvipc/ .cpuinfo .ioports .misc slabinfo fs/ tty/
- modules
-
Protože jsem v dílu číslo devět u popisu souboru ksyms sliboval, že v tomto dílu se podrobněji rozpovídám o modulech, bylo by asi vhodné zmínit, že tak zatím neučiním. Důvodem je to, že se ozývají čtenáři, kterým se moje články zdají až příliš rozvláčné. Pokud bych měl ještě o modulech psát, byly by to většinou věci, které drtivá většina lidí bude považovat za zcela zbytečné. Proto, pokud přece jen máte zájem vědět, jak systém modulů, jejich zavádění a případně i programování vypadá, napište mi (na email nebo do diskuse) a dle ohlasů uvidím, co s tím.
Zde je možné nalézt přesně to samé, co říká příkaz lsmod. Seznam zavedených modulů, jejich velikosti a návaznosti na ostatní moduly:
NVdriver 659104 15 (autoclean) nls_cp437 4384 1 (autoclean) via686a 8496 0 (unused) i2c-proc 6144 0 [via686a] i2c-isa 1200 0 (unused) i2c-core 13168 0 [via686a i2c-proc i2c-isa] apm 9072 2 nls_iso8859-2 3376 2 (autoclean) nls_cp852 3616 1 (autoclean) vfat 9424 2 (autoclean) fat 32288 0 (autoclean) [vfat] esssolo1 24672 0 gameport 1904 0 [esssolo1]
Myslím, že význam je docela jasný, ale přece jen. První sloupec je název modulu. Odpovídá názvu souboru v adresáři /lib/modules/verze_jadra/…/jmeno_modulu.o. Název souboru může být také bez přípony .o, jak je tomu u ovladače grafické karty, kde se soubor jmenuje pouze NVdriver.
V dalším sloupci je velikost modulu. Tohle číslo není stejné jako velikost souboru s modulem, stejně jako obraz spuštěného procesu v paměti není nikdy kopií binárního souboru, ze kterého je proces spuštěn (ani ihned po startu). Velikost modulu je dána součtem velikostí vlastního kódu, konstantních a staticky inicializovaných dat a případných administrativních položek.
Následující číslo udává počet použití modulu. Na první pohled tedy vypadá zajímavě, že některé moduly mají na tomto místě nulu. Například modul fat je na první pohled aktivní (připojený oddíl se souborovým systémem FAT), ale počet použití je nula. Tohle číslo spravuje interně sám modul, a to pomocí dvou funkcí (maker), jedné pro inkrementaci (MOD_INC_USE_COUNT) a druhé pro dekrementaci (MOD_DEC_USE_COUNT). Existuje ještě třetí makro pro zjištění aktuálního stavu tohoto počitadla (MOD_IN_USE). Tato makra manipulují s položkou usecount v tabulce informací o modulech v jádře. Přímý přístup se neprovádí proto, že kromě kontrol zajistí tato makra také atomičnost těchto operací, což může být (na SMP strojích, při práci s přerušeními) velmi důležité. Jejich definici naleznete v include/linux/module.h. Makra se používají v praxi tak, že pokud někdo provede operaci nad zařízením (často otevření odpovídajícího souboru v adresáři /dev), zvýší odpovídající funkce v ovladači počet použití, protože zařízení někdo používá. Naopak při uvolňování zařízení (uzavření souboru) je počet snížen.
Poslední sloupec udává příznaky modulu a jeho závislosti. Závislosti jsou použity utilitami depmod a modprobe pro (polo) automatické nahrávání sady modulů. Pokud chci například ovladač tiskárny (modul lp), stačí zadat modprobe lp, a pomocí definovaných závislostí jsou nataženy i moduly pro paralelní port (parport, parport_pc). Dále jsou závislosti použity při odstraňování modulů. Nelze odstranit modul, na němž je jiný modul závislý. Závislosti jsou zobrazeny jako seznam (v hranatých závorkách) modulů, které daný modul využívají. Příznaky jsou uvedeny v kulatých závorkách. Asi nejčastějším příznakem je autoclean. Ten je nastaven, pokud modul zavede samo jádro „on demand“, případně při použití parametru -k (–autoclean) pro utility modprobe (insmod). Takto označené moduly mohou být potom automaticky odstraněny, nejsou-li delší čas používány (zpravidla ~ 1 minuta). K odstranění může být použit třeba cron, volající opakovaně příkaz k odstranění modulu rmmod -a. Parametr -a provádí právě odstranění všech nepoužívaných modulů.
Soubor mounts přeskočím a nechám na příště, rád bych mu věnoval více času, než mám teď k dispozici (asi hodina na odevzdání :).
- mtrr
-
MTRR znamená Memory Type Range Register. Jedná se o věc specifickou pro architekturu Intel x86. (Při hledání v adresářích se zdrojáky jádra jsem našel zmínku ještě u sparc64, ale SPARC bohužel neznám, takže by případné informace byly jen dohady.) Tento rys je k dispozici na procesorech rodiny P6 – tedy PPro, PII, PIII, PIV :). Obdobné mechanismy je možné nalézt také na procesorech Cyrix, AMD, WinChip nebo Cyrix. A o čem to vlastně je?
reg00: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xd8000000 (3456MB), size= 32MB: write-combining, count=1 reg02: base=0xd0000000 (3328MB), size= 32MB: write-combining, count=1
Jak bystrý čtenář jistě instinktivně vycítí, jde o sady registrů, které umožňují kontrolovat přístupy k oblastem paměti. Oblast je dána offsetem (adresou počátku) v LAP (logickém adres. prostoru) a velikostí oblasti. Dále je evidován typ oblasti, tedy typ prováděné kontroly, a počet použití oblasti.
Pro nás bude zajímavý typ write-combining. Ten se používá pro grafické karty na sběrnicích PCI nebo AGP. Tento mód umožňuje kombinovat zápisové operace přes tyto sběrnice do větších celků a posílat je najednou. To zvyšuje výkon některých grafických operací (dle Documentation/mtrr.txt až 2.5 krát). V uvedeném výpise používá XServer dvě oblasti o velikosti 32 MB ke kontrole zacházení se zápisy do grafické paměti.
Soubor /proc/mtrr je jedním z rozhraní určených k ovládání těchto registrů. Zápisem nového řádku je možno kontrolovat chování dalších registrů. Druhým způsobem (používaným třeba v ovladačích framebufferu) je rozhraní ioctl. Způsob manipulace je pro obě rozhraní detailně (i s příklady) popsán v dokumentaci v Documentation/mtrr.txt.
ČLÁNKY DO MAILU