Cesta do hlubin kompilace jádra - 3

14. 10. 2005 | Antonín Kolísek | Návody | 11690×

Kompilovat moduly nebo dávat přímo do jádra? Popis konfiguračních voleb určujících stabilitu kódu, obecná nastavení a podporu modulů.

Na úvod

Po předběžných informacích o sestavení jádra a hledání informací o hardware jsme nyní připraveni podstoupit nejtěžší a nejvýznamnější krok. Tímto krokem je samotný výběr součástí, které naše jádro bude obsahovat. Je to nejen důležitý, ale také poměrně rozsáhlý úkon, který nepůjde popsat v jednom díle. Proto se budu v následujících dílech seriálu, počínaje tímto, zabývat touto problematikou. Veškeré oparece budu provádět s aktuálně nejnovějším jádrem 2.6.13 (nebo 2.6.13.X), proto se mohou některé volby nepatrně lišit při použití jiné verze jádra řady 2.6.

Modul nebo přímo do jádra?

Při výběru komponent dostaneme většinou na výběr, zda chceme vybranou součást kompilovat přímo do jádra nebo jako modul. Při volbě první možnosti je pak vybraná funkce nebo ovladač přímo součásti jádra, tedy komprimovaného obrazu jádra (bzImage). Při volbě kompilace jako modul dojde k sestavení binárního souboru, tzv. modulu, který je v případě potřeby nahrán k běžícímu jádru (a při nečinnosti může být teoreticky z jádra opět odebrán).

Jaký model jádra zvolit, zda spíše monolitický (co nejvíce věcí přímo do jádra) nebo modulární (nutné věci přímo v jádře, vše ostatní jako modul), nejde přesně říci. V dnešní době má Linux velmi propracovaný systém pro práci s moduly, a tak se jeví jako nejvhodnější kombinovat obě možnosti. V některém případě (bude-li potřeba, vždy upozorním) je doporučeno dát součást přímo do jádra (např. ovladač IDE řadiče, ovladač filesystému pro kořenový oddíl,...) a jinde se doporučuje kompilovat součást jako modul (ALSA, agpgart,...).

Dalším důvodem, proč používat moduly, je fakt, že v některých případech, kdy dojde například ke špatné komunikaci mezi ovladačem a hardware, může dojít až k pádu systému, je-li ovladač přímo v jádře. V případě použití modulu nemusí být následky tak velké, což nemusí ale vždy platit. Určitě to ale při volbě modulů můžeme brát jako nepatrné plus.

V mém případě se zde budu snažit dát pouze nutné věci přímo do jádra a většinu ostatního kompilovat jako moduly. Pokud si člověk nebude jistý, zda dát vybranou věc do jádra nebo jako modul, má možnost ponechat výchozí nastavení, čímž většinou nic nepokazí.

Výběr součástí jádra

Na začátku popíši, jak bude vypadat výběr jednotlivých komponent v rámci tohoto seriálu, aby se čtenář mohl lépe orientovat. Každá komponenta bude označena přesným jménem, popisem a vždy bude vyznačeno, zda je dobré ji kompilovat jako modul nebo do jádra. Více ukáže následující příklad:

Jméno komponenty [M,Y,N]

M = modul, Y = do jádra, N = nezačlenit

---

Code maturity level options --->

Prompt for development and/or incomplete code/drivers [Y]
Select only drivers expected to compile cleanly [Y]

Povolíte-li první volbu, budou v konfiguračním programu zobrazeny i volby komponent/ovladačů, které jsou ve fázi testování nebo nedokončené. Výběr je nutný, neboť některé komponenty, ač ve fázi testování, budeme potřebovat. Druhá volba ponechá ve výběru konfiguračních voleb jen ty ovladače, jež lze zkompilovat bez chyb.

---

General setup --->

Tato sekce se týká všeobecných nastavení komponent jádra. Především však funkcí pro meziprocesorovou komunikaci. Je možno vše ponechat jako povoleno.

Local version - append to kernel release

Zde je možné nastavit doplňující jméno kernelu, které bude připojeno k verzi jádra (např. 2.6.13-mujlinux1)

Support for paging of anonymous memory (swap) [Y]

Povolení užívání swapovacího oddílu nebo swapovacího souboru v případech, kdy je potřeba více paměti než je celková paměť RAM. Tuto volbu určitě vybrat.

System V IPC [Y]

Podpora pro meziprocesovou komunikaci, kterou využívají například emulátory jiných OS (DOSEMU,..). I když přímo emulátory nebudete používat, doporučuji dát tuhle věc do jádra.

POSIX Message Queues [Y]

Řazení hlášení dle normy POSIX; z našeho pohledu ne příliš důležité volba. Nicméně dle výchozí konfigurace necháme v jádře.

BSD Process Accounting [Y]
BSD Process Accounting version 3 file format [Y]

Předávání informací o procesu. Doporučeno dát do jádra.

Sysctl support [Y]

Podpora pro dynamickou změnu parametrů jádra. Změna parametrů jádra probíhá prostřednictvím adresáře /proc/sys (k tomu je nutné povolit i souborový systém /proc). Velmi doporučená volba.

Auditing support [Y]
Enable system-call auditing support [Y]

Povolení podpory auditu, kterou používají speciální subsystémy (např. SELinux, Grsecurity, ...). Ponechání této podpory v jádře nás nijak významně při jejím nevyužití neovlivní.

Kernel Userspace Events [Y]

Mechanizmus pro komunikaci přes netlink socket. Ve výchozím nastavení povoleno pro kompilaci do jádra.

Kernel .config support [Y]
Enable access to .config through /proc/config.gz [Y]

Z této sekce pro nás velmi důležitá volba. Při povolení této položky dojde k uložení konfigurace jádra (.config) do samotného obrazu jádra (bzImage). Konfigurační soubor je pak k nalezení v /proc/config.gz.

Configure standard kernel features (for small systems) ---> [N]

Zde je možné při akceptování vybrat různé volby týkající se především optimalizace pro embedded zařízení. Pro normální použití tuto volbu zamítáme.

---

Loadable module support --->

Sekce týkající se podpory pro práci s moduly.

Enable loadable module support [Y]

Podpora pro nahrávání modulů do jádra (po kompilaci uloženy v adresáři /lib/modules/verze-jádra/kernel/) Velmi důležitá funkce - povolíme.

Module unloading [Y]

Další velmi praktická funkce. Umožňuje odebrání modulů z jádra, není-li daný modul používaný.

Forced module unloading [Y]

Funkce užívaná spíše u vývojářů kernelu. Nicméně se může někdy hodit, proto doporučuji akceptovat. Jedná se o odebrání modulu z jádra silou za použití programu rmmod (rmmod -f). Tím dojde k odebrání modulu + ostatních modulů které na odebíraném modulu závisí.

Module versioning support (EXPERIMENTAL) [N]

Tímto povolíme podávání informací o modulech. Tato volba má význam pro vývojáře kernelu, proto je pro nás nepotřebná. Volbu ignorujeme.

Source checksum for all modules [N]

Podobný případ jako v předchozím. Pro normální použití nepodstatná funkce, proto ji nebudeme akceptovat.

Automatic kernel module loading [Y]

Velmi praktická funkce. Umožňuje automaticky nahrávat moduly do jádra v případě potřeby. V případě absence této funkce by se musely moduly nahrávat manuálně programem modprobe. Určitě volbu akceptovat.

Závěr

Probrali jsem tímto dílem první tři subsystémy jádra. Příště se podíváme na subsystémy týkající se procesoru a správy napájení.

       

Komentáře

[camlost]

které na odebíraném modulu zívisí

[Robert Krátký]

Opraveno. Díky.

[Tomáš Šimek]

V tuto chvíly se mi zdá článek pouhým a navíc zjednodušeným překladem kontextové nápovědy k jádru.

Je ale pravda, že článek by měl popisovat praktické aspekty jednotlivých voleb, a u těchto položek prostě není co popisovat (na zadané rozlišovací úrovni)

V dalších dílech ale očekávám rozvedení voleb (volba architektury, proč mohu dát ovladače na IDE chipsety jako modul, když IDE potřebuju při startu, initrd či neinitrd, jaký je rozdíl mezi watchdog a hangceck timer, kolik HZ zvolit, jakou preempci, jestli je výhodnější high mem off ..............), zkrátka spoustu věcí které mne vždy zajímali, ale nikdy nestály za tu námahu (zjištění/odzkoušení).

Pokud bude autor pokračovat 2řádkovým překladem, a 5ti slovným doporučením, pak bych ho musel šikanovat (komentářem samozřejmě)

[Jan Hluštík]

Připojuju se s žádostí o víc podrobností. Pokud by ale nebyly, i tak mi článek pomůže. Díky.

[Antonín Kolísek]

V dalších dílech bude vše potřebné pro ty co začínají s kompilací jádra. Pokročilý ať hledá jinde. Všem se zavděčit nemohu. Takže pro koho je tento seriál přínosným, ať jej čte a nalezne v něm co potřebuje. Kdo v něm něco nenalezne, ať hledá jinde a neoptěžuje se s komentáři že to zde není. Opakuji všem se člověk nezavděčí. Jinak rozvedení voleb o které žádáte bude v dalších dílech samozřejmě popsáno.

[%]

No a jak je to teda s tim ifconfigem ROFL

[Luk]

Module versioning support není podávání informací o modulech, nýbrž kontrola verzí modulů. Jádro pak odmítá zavést moduly s jinou verzí než má samo.

[J]

Jeste jinak, tato volba ovlivnuje, zda kernel umozni (Y) ci neumozni (N) nahrat modul kompilovany proti jine verzi jadra. To vse ovsem bez naroku na funkcnost takoveho modulu, jen se tomu zkratka nebude branit hlaskou o spatne verzi. Vyhody jsou zrejme, pokud mate modul jako binarku proti nejake verzi, tak jej muzete pouzit i ve verzi novejsi, pokud se ovsem nezmenil kod na kterem zavisi onen modul.

[diverman]

[flame] Používám monolytické jádro. Co vy? [/flame]

[watslaw]

Používám většinou moduly, v jádře mám jen IDE, ext3, reiserfs, framebuffer, logo apod., co je potřeba při startu, aby nemusel bejt initrd.

Moduly mají tu výhodu, že některé experimentálnější (fuse, reiser4) mám zavedeny jen když je používám a neohrožují mi stabilitu jádra, a pak kvůli možnosti odstranění.

Např. moje zvuková karta se občas rozhodne místo fungování vrčet, a pomůže akorát rmmod snc_via82xx + modprobe snd_via82xx, kdyby to bylo v jádře, musel bych restartovat (Mmch příčinu neznám, kdyby náhodou někdo věděl co s tím).

Další výhoda modulů je to, že se občas rozhodnu přidat podporu nové věci nebo toho, na co jsem při kompilaci zapomněl. Přikompilovat modul je značně jednodušší.

[vendin]

jak kdy a jak na co:
1) router nebo jiny jednoucelovy system: spise monolyticke jadro
2) stanice: tak pul na pul, zejmena moduly hotplug zarizeni atd... 3) notebook: spice vic modulu kvuli pcmcia,... 4) system na vymennem disku: maximalne modulu, radice na scsi atd. v initrd, pak neni problem prenositelnost os

[Spike]

Raději monolitické, lidi.

[Lukas Lipavsky]

Osobne mi prijde nejlepsi, mit spolehlive a casto pouzivane veci napevno v jadre, ostatni v modulech. Mam subjektivni pocit, ze ty veci v modulech musi mit vetsi rezii (subjektivni dojem, pokud me nekdo nepresvedci o opaku :)))

[azurIt]

ja mam zase uplne vsetko v jadre :) samozrejme je to jadro site na mieru pre moj comp. moduly nemam rad a nedar ich aj pouzivam - asi koli tomu, ze vela adminujem linuxove servere a tam sa uz aj podpora modulov povazuje za insecure.

inak jediny modul, ktory pouzivam je driver od nvidie :) (na desktope)

[Libor Klepac]

vzdyt on ma taky vsechno v jadre ;)

[azurIt]

to som skor myslel ako reakciu na vsetky tie prispevky pred tym :)

[Libor Klepac]

mam vetsinu veci v modulech, i ovladac fs, ze ktereho bootuju, cele ide, i sata ...vlastne kvuli sata to mam, nejak mi to nenachazelo disky, kdyz byl ovladac napevno v jadre

[J]

Pouzivam jadra vyhradne modularni (az na detaily jako fs / a ide). Duvodem predevsim moznost do kernelu dodat co zrovna treba, pripadne patchout jen prislusny modul a restartnout jen dane zarizeni.

[Vasek]

dalsi nevyhodu monolytickeho jadra bych uvedl velkou velikost. kdyz je moc velke 1) nevejde se na rescue disketu 2) nekdy nejde pouzit lilo (grub uz je ok)

pak mi take vadi, ze jsou zavedene i veci, ktere zrovna nepotrebuju. mapriklad filesystemy pro vymenna zarizeni (cd-rom, FAT pro usb, ...)

[Peter Rychnavský]

Já by som chcel oceniť seriál. Toto mi vždy chýbalo. Ďík zaňho.

[Tabak]

Muzu se zeptat, nikde sem se zatim nedozvedel (omlouvam se jestli sem to tu nekde prehlidl). Pokud to dobre chapu, tak zkompilovanne jadro je v souboru bzImage, moduly v /lib/modules/x.y.z a co je vlastne v tech souborech system.map a vmlinux? A jak souviseji s bzImage? Dik

[koudelka]

Zdravim, clanek je velice zajimavy, ale jiz dlouho nebyl doplnen o dalsi sekci. Vim, ze vsichni, kdo prispivaji a pomahaji nam zacatecnikum, tak vse delaji zadarmo. Presto se ptam: Bude pokracovani tohoto clanku? Kdy?

Diky.

[menphis]

moc prosim, nemohl by nekdo dopsat ten dalsi dil, pripadne aktualizovat ohledem na dnesni verzi jadra. :)