Jaderné noviny – 19. 7. 2012: Snazší nastavování jádra

6. 8. 2012 | Luboš Doležel | Jaderné noviny | 3344×

Aktuální verze jádra: 3.5-rc7. Citáty týdne: Matthew Garrett, Linus Torvalds. 30 jaderných vývojářů během 30 týdnů: Dave Jones. Konfigurace jádra pro distribuce.

Obsah

• Aktuální verze jádra: 3.5-rc7
• Citáty týdne: Matthew Garrett, Linus Torvalds
• 30 jaderných vývojářů během 30 týdnů: Dave Jones
• Konfigurace jádra pro distribuce

Aktuální verze jádra: 3.5-rc7

Aktuální vývojová verze jádra je 3.5-rc7 vydaná 14. července. Hele lidi, vzpomínáte na to, jak se všechno zklidňovalo a zpomalovalo a všichni jaderní vývojáři byli na letní dovolené? No, tak o tom si spolu musíme pěkně popovídat.

Stabilní aktualizace: verze 3.0.37 a 3.4.5 vyšly 16. července; verze 3.2.23 vyšla 13. července. Verze 3.0.38 a 3.4.6 se aktuálně revidují.

Citáty týdne: Matthew Garrett, Linus Torvalds

Nerad bych toto musel někomu vysvětlovat [...]

-#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
+#define HV_LINUX_GUEST_ID_HI		0x0DEFACED

-- Signed-off-by: Matthew Garrett

A aby to bylo ještě horší, „x" bylo samo o sobě výsledkem “*&y". Což bylo asi napsáno Maxem, starším bratrem šílené opice, který strávil několik let žvýkáním metaqualonu, následkem čehož na tom jeho mozek také nebyl moc dobře. I na opici. A teď zrovna *jeho* pouštíš ke své klávesnici?

-- Linus Torvalds

30 jaderných vývojářů během 30 týdnů: Dave Jones

Na Linux.com vyšel rozhovor s Davem Jonesem, správcem jádra ve Fedoře, a to v rámci seriálu o jaderných vývojářích. Potřeboval jsem si sestavit vlastní jádro, protože ani jedno z distribučních nepodporovalo funkci, co jsem potřeboval. A tato funkce byla v té době dostupná jen ve vývojovém stromě (což tehdy bylo 2.1.x). Už ani nevím, co to bylo, ale možná to bylo něco hloupého jako VFAT. Ne vždycky bylo jádro stabilní, tak jsem si navykl jej pravidelně aktualizovat (z univerzity jsem si domů odnášel poslední tarball vždy na ZIP disketě). Začal jsem posílat patche, kdykoliv jsem narazil na něco, co bych mohl vylepšit. Už si nemohu vzpomenout na svou první skutečně významnou věc. V řadě 2.1.x jsem opravoval AFFS. Předtím šlo o desítky drobností.

Konfigurace jádra pro distribuce

Nastavování jádra dříve bývalo přímočaré, stačilo jen vědět, pro jaký hardware je třeba mít podporu. Časem se to trochu zkomplikovalo, hlavně ale distribuce začaly záviset na konkrétních funkcích jádra – pro běžného uživatele může být obtížné tyto závislosti zjistit. To vedlo Linuse Torvaldse k sepsání návrhu RFC, aby do jádra byly zařazeny konfigurační volby pro konkrétní distribuce.

Problém má svůj původ v tom, že uživatelský prostor distribuce vyžaduje pro správné fungování zapnutí některých konfiguračních voleb. Věci jako tmpfs a devtmpfs, řídící skupiny, bezpečnostní volby (jako SELinux, AppArmor) a dokonce i podpora surových tabulek netfilter byla zařazena na seznam voleb „podpůrné infrastruktury“, jež různé distribuce vyžadují. Kromě toho, že je těžké na toto všechno přijít, se tyto volby časem mění, takže konfigurace použitelná pro Fedoru N nemusí fungovat na Fedoře N+1. Výsledné problémy může být těžké odhalit, jak Torvalds poznamenal: Párkrát se mi už stalo, že jsem začal se svým minimálním config souborem a výsledné jádro sice nabootovalo, ale některé věci nefungovaly zrovna správně a může jít o dosti nenápadné problémy.

Proto navrhl přidání souborů Kconfig pro konkrétní distribuce:

Postupně se dostávám k tomu, že bych velice rád viděl *distribuční* soubory Kconfig, kde by distribuce mohly určit svou minimální konfiguraci, se kterou budou fungovat. Takže bychom měli podmenu „Distribuce“, kde byste si mohli vybrat svou distribuci a pak i verzi [...] což by to značně usnadnilo obyčejným uživatelům (a upřímně řečeno bych se do této skupiny také rád zařadil) vytváření jaderných konfigurací, které zkrátka fungují.

Našla by se i jiná řešení, ale ta by měla své nedostatky. Kopírování distribučního souboru config by mohlo stačit, ale znamenalo by to spoustu nadbytečných voleb, které nejsou pro správné fungování distribuce skutečně zapotřebí. Používání make localmodconfig (které vybere všechny volby podle spuštěného jádra) trpí v podstatě tím samým problémem, jak říká. Cílem je to, aby jádra dokázalo sestavovat více lidí.

Skutečně si myslím, že „jak stvořím config soubor pro jádro“ je problémem, který od kompilace vlastního jádra odrazuje spoustu lidí. Ale my *chceme*, aby si lidé kompilovali vlastní jádra, aby nám mohli pomoci třeba s bisect atd. Čím více, tím lépe.

Na linux-kernel se nápad setkal se souhlasem. Vyskytly se obavy o to, jak by soubory distribucí byly udržovány a že někdy nemusejí odrážet aktuální požadavky. Dave Jones poznamenal, že je občas požadavky na jádro ve Fedoře zaskočen (a to je jeho správcem).

Torvalds dává jasně najevo, že nehledá dokonalé řešení, ale spíše prostě jen něco lepšího: i config soubor postavený na základě kvalifikovaného odhadu je lepší než to, co máme teď. V tomto mailu popisuje dva požadavky, které na funkci má. První je to, že každá konfigurační volba nastavená pro určitou distribuci musí u sebe mít vysvětlení, proč je zapotřebí. Druhým je to, že musí jít o sadu minimálních voleb, které jsou nutné pro správné fungování systému – a ne že to bude mít nakonec všechny volby jen proto, že se někdo rozhodl přidávat náhodné volby, dokud to nezačalo fungovat.

Okomentování vyžadovaných voleb může ale být obtížné i pro ty, co pracují přímo s distribučními jádry. Ben Hutchings (který spravuje jádro Debianu) upozornil, že ani on sám nemusí znát důvod, proč byla určitá volba povolena, zejména, když už je to delší doba: jen to, že někdy bylo o volbu požádáno kvůli podpoře čehosi v uživatelském prostoru, neznamená, že vím, co to používá nebo co na tom závisí teď.

Je ale možné povolit i další volby. V původní zprávě Torvalds zmínil konfigurace pro „běžné platformy“ jako „moderní notebook“, které by vybraly to, co je pro ně nutné (USB storage, FAT/VFAT, správa výkonu apod.). Konkrétně řekl, že nastavení platformy by mělo být považováno za věc oddělenou od myšlenky distribucí.

I uživatelé KVM (a jiných virtualizací) měli zájem o vytvoření volby, která by vybrala všechny ovladače a další volby nutné pro tato jádra. Aktuálně musíte prolézt přes >30 různých menu, abyste našli všechno to, co je pro běh základního systému pod KVM potřeba; tak to popsal Trond Myklebust. O nutnosti přidání lepších voleb pro virtualizaci se diskutovalo hodně, ale to už se téma dostalo od původního Linusova návrhu dost daleko.

Není překvapením, že jaderní vývojáři začali přemýšlet nad tím, jak by právě oni mohli tuto funkci zužitkovat. Vyskytly se obavy, že zvolení konkrétní distribuce a jejích závislostí by jaderným vývojářům mohlo ztížit další úpravy nastavení. David Lang měl konkrétní stížnosti na postup navržený v RFC – například by bylo těžké vybrat jádro pro Fedoru bez SELinuxu. Ale Torvalds dal jasně najevo, že Lang a ostatní jaderní hackeři nejsou cílovou skupinou.

To, oč žádám, je pro obyčejné lidi. Pro lidi, které konfigurační soubor NEZAJÍMÁ, a jen chtějí sestavit jádro pro svůj stroj.

Nekomplikujte věc kladením zcela nesouvisejících otázek. Neničte funkci užitečnou pro 99 % lidí jen proto, že nejste mezi nimi.

Potěšit všechny může přesto být možné – Lang si to tak jako tak myslel – ale než někdo dodá nějaký ten kód, je těžké o tom mluvit. Ačkoliv se všichni shodli, že funkce může být užitečná, nikdo se nehlásil jako dobrovolník. Zda šlo Torvaldsovi jen o to nadhodit myšlenku a nechat někoho jiného to uskutečnit, není jasné, ale vypadá to jako něco, co by stálo za to mít.

       

Komentáře

[pavlix]

To vedlo Linuse Torvaldse k sepsání návrhu RFC, aby do jádra byly zařazeny konfigurační volby pro konkrétní distribuce.

A to se zrovna snažím vykopat zbytečné závislosti na distribucích z NetworkManageru. Názor Linuse hodně moc uznávám, ale v tomhle případě se mi zdá, že to není ústupek na správném místě.

[Michal]

Me to pripada jako docela dobry napad, ale nemyslim si ze je vhodne to cpat primo do jaderneho stromu, tam ty konfigurace stejne nebude nikdo udrzovat. Spis by byla dobra nejaka wiki typu "Pro distribuci X a jadro Y je potreba tenhle minimalni config + ovladace vaseho HW".

Ja jsem pred par tydny potreboval do RHEL 5 nacpat jadro 2.6.38 a trvalo mi HODNE dlouho nez jsem prisel na tu spravnou kombinaci voleb ktere to potrebuje k zivotu. I tak jsem nakonec musel spoustu veci zakompilovat natvrdo do jadra protoze z mission initrd se postupne vyklubalo mission impossible.

[motorka]

Já bych také přivítal nějakou tabulku jako "hardware:ovladač" takže by se v závislosti na nalezeném hardwaru přidal konkrétní ovladač. Popřípadě pro notebooky celá konfigurace, u kterých většinou hledám informace na wiki. Hledání správných ovladačů není vždycky nejjednodušší úkol, občas se mi stává, že na něco zapomenu (a nebo zbytečně přidám) a úspěšně bootuji až třetí konfiguraci jádra kdy mi všechen hardware funguje.

[Conscript89]

Pokud nejde o gentoo, nebo je to gentoo live (desktop) tak by melo stacit lsmod a z toho zjistis jaky drivery chces, ne? Samozrejme to nebude identicky seznam, ale i tak to podle me staci.

[Dreit]

http://kmuto.jp/debian/hcl/ tohle?

[motorka]

Ano

[Conscript89]

Podle me by naprosto stacilo, kdyby v distribuci byly balicky: kernel-config kernel-config-minimal napr. Sam bych to uvital :)

[Michal]

/proc/config.gz? Pripadne to nekdy byva v /boot/config-* I kdyz to pravda nebyva ten minimalni.

[Conscript89]

Diky, o tom jsem nevedel, ze bych si zase zacal kompilovat jadro?
Fedora 17 nema v /proc soubor config.gz (ani zadny podobny), ale ty co jsou v /boot mi bohate staci.

[avzgag]

jednak na hracicky a kompilace vlastnich jader neni cas, ale taky me odrazuje milion voleb v menuconfigu.

[marbu]

Nebo pokud te to vic zajima, muzes se primo podivat, jak se dela distribucni jadro:

fedpkg clone --anonymous kernel

Tak si naklonujes git repozitar se vsemi skripty, patchi a konfiguraky. Btw treba v README.txt se pise:

config heirarchy.
-----------------
Instead of having to maintain a config file for every arch variant we build on,
the kernel spec uses a nested system of configs.  At the top level, is
config-generic. Add options here that should be present in every possible
config on all architectures.

Beneath this are per-arch overrides. For example config-x86-generic add
additional x86 specific options, and also _override_ any options that were
set in config-generic.

The heirarchy looks like this..
                                                                                                                               
                           config-generic                                                                                      
                                 |                                                                                             
                         config-x86-generic                                                                                    
                         |                |                                                                                    
             config-x86-32-generic   config-x86-64-generic                                                                     
                                                                                                                               
An option set in a lower level will override the same option set in one                                                        
of the higher levels.                                                                                                          
                                                                                                                               
                                                                                                                               
There exist two additional overrides, config-debug, and config-nodebug,                                                        
which override -generic, and the per-arch overrides. It is documented                                                          
further below.                                                                                                                 

[Michal Kubeček]

I když není povolená prezentace přes /proc/config.gz, je pořád možné, že je konfigurace v jádře obsažena a dá se z něj vytáhnout pomocí scripts/extract-ikconfig (viz volby CONFIG_IKCONFIG a CONFIG_IKCONFIG_PROC).

[Kvakor]

Optimální by bylo mít podobné balíčky jako součást virtuálního balíčku pro překlad vlstního jádra, kde by byly zároveň závisloti pro nutné nástroje pro překlad a sestavení jádra (obdoba debianího buil-essential).

Docela by se to hodilo i pro ne-x86 platformy (rozličné SoC ARMy obzvlášť), kde je docela problematické zjistit, co tom kterém zařízení je (u x86 je alespoň lspci), takže pokud distribuční/defaultní jádro nemá vestavěný .config.gz, tak to znamená spousta googlení, prolézání hlášek jádra a zkoumání jednotlivých obvodů na desce.

Já osobně používám na svých strojích vlastní jádro "odjakživa" a mám přehled, co je potřeba a co ne, ale kdybych musel dělat jádro pro jinou distribuci než Debian nebo specializovaný pseudo-LFS, tak bych podobný přehled toho, co je třeba zapnou, uvítal.

[Ondrej 'SanTiago' Zajicek]

Co tam je by melo jit zjistit ze /sys/devices . Tam by idealne melo byt vsechno vcetne ruznych platform devices (resp. to, pro co ma jadro ovladac), pokud to tedy neni nejake historicke 2.4.x jadro s vyrobcem-specifickymi zbastlenymi patchi.

[Roman Došek]

Co takhle toto Kernel-Seeds.org

Není nic jednoduššího než si odsud stáhnout config a jen do něj doplnit podle lspci výstupu potřebné ovladače...

[Petr Ježek]

Zbytečně závislosti NM lze elegantně vyřešit jeho odistalováním a nahrazením Connmanem...

[pavlix]

Zbytečně závislosti NM lze elegantně vyřešit jeho odistalováním a nahrazením Connmanem...

Co by mi to přineslo?

[Lol Phirae]

Přece nucenou odinstalaci spousty "zbytečných" balíčků, které nějaký connman absolutně nezajímá.

[w4rr10r]

Změnu zaměstnání.

[pavlix]

Tak asi spíš změnu projektu :).

[CLX-Kuba]

Konfigurace jádra pro distribuce: Konecne nad tim nekdo zacal uvazovat, osobne bych uvital nejaky defaultni konfigurace pro virtualni stroje VMware ESX/Workstation, KVM, Xen atd... Jelikoz tam sem nejvic casu travil hledanim nejakyho driveru bez ktereho mi to treba ani nebootovalo a tedka tam mam urcite haldu veci uplne zbytecne... Otazka zda to davat primo do jadra nebo donutit jednotlive distribuce aby obsahovaly dane config soubory. Napr. v balicku VMware-tools by mohly tyto config soubory bejt primo od VMwaru.