Kernel Traffic #224 For 30 Jul 2003

Byl vydán testovací balík projektu Linux Test. Poslední verze testovacího balíku obsahuje více než 2000 testů pro OS Linux. Naše webové stránky zároveň poskytují další informace: výsledky testů, přehled linuxových testovacích nástrojů, místo pro shromažďování oprav známých závažných problémů v 2.5 kernelech, technické dokumenty a HowTo o linuxovém testování a nástroj vyhodnocující pokrytí kódu.

To hlavní:

• Zařazení testovacího balíku OpenHPI (Hardware Platform Interface: rozhraní pro hardwarové platformy).
• Nové testy PCI, USB, ACPI a NLS filesystému
• Opravy a vyčištění kódu pro IA64 a PowerPC64
• Byly aktualizovány další skriptové testy, aby používaly testovací API.
• Nové logo!

Doufáme, že budou lidi posílat výsledky, patche nebo nové testy do naší konference a využívat CVS k hlášení problémů, na které při používání testovacího balíku narazí.

Ok. Je to tady. Andrew a já se chystáme začít "pre-2.6" sérii, do které bude mnohem těžší protlačit patche. Nezapomeňte, že tohle je poslední 2.5.x kernel.

Za povšimnutí asi nejvíce stojí anticipatory scheduler, který byl dlouhou dobu v -mm, a byl to poslední kousek, který zbývalo začlenit.

Pár aktualizací architektur: cris bylo dovedeno na 2.5, ia64 a arm26 byly také aktualizovány. A ještě několik menších věcí.

No, tak k tomu mohu říct jen dvě slova. Do p*dele.

2.5.70 ARM patch teď vypadá nějak takhle:

343 změněných souborů, 45388 příspěvků(+), 7341 výmazů(-)

a nezdá se mi, že by se to mělo nějak zklidnit, když je teď 2.6 za rohem.

Já _vím_, že ARM není možné zkompilovat a v Linusově stromu to už nejde nějaký čas - je tu pár obecných změn potřebných v vmalloc.c pro podporu ARM modulů - a zatím jsem neměl čas je protřídit. A stále je tu ten problém, že nevíme, jestli /proc/kcore vůbec funguje - a teď vidím, že časové věci potřebují zase předělat hned pro několik ARM platforem. (Ano, všechny ostatní architektury kromě ARM aktualizovány byly.)

Možná bych měl prostě vzdát pokusy o začlenění do hlavního stromu. Jako většina lidí v ARM komunitě.

Rozčílenej je slabý slovo.

Můžeme to vyřešit později. Je jasné, že čistě ARM patche (tj. věci v arch/arm a include/asm-arm) by mi nevadily, ale radši bych počkal i s těmi, jen aby bylo jisté, že se patche a changelogy nepomíchají s "hlavní opravami".

Nikdy jsme neměli první stabilní verzi, která by měla aktualizované všechny architektury, a neplánuju v tomto ohledu změnu ani pro 2.6.x. Vzhledem k tomu, že můj strom už dlouho není hlavním ARM stromem, není teď ta správná chvíle na pokusy o kompilaci mého stromu na ARM (nebo jiných architekturách).

Abych to řekl bez obalu, které části z "chceme vydat 2.6.x tento rok" ti připadají jako překvapení?

To znamená, že už nejsem ochoten dále věci zdržovat. Věci, které nesledovaly vývojový strom se "nespraví" nějakým kouzlem.

Jediným opravdovým důvodem vydání stabilního jádra jsou výrobci distribucí. Což zúží seznam "nutné podpory" na x86, ia64, x86-64 a možná sparc/alpha.

Takže všechno ostatní je bonus, ale můžete nás později zase dohánět. Lidi, kteří dělají s embedded, radši zůstavají pozadu, což je pochopitelně důvod, proč nesledují vývojový strom.

Tobě to připadá smutné, ale já to neberu jako selhání. Proč by měl jeden strom být pro všechny? Chceme to usnadňovat udržováním vazby tak, že se snažíme o přenositelnou infrastrukturu, atd. Ale filosofie, která by říkala "ve stromě X musí všechno fungovat" by nás omezovala. Znamenalo by to prostě, že bychom si nemohli dovolit nic kazit.

Daleko raději bych si ponechal volnost věci kazit a mít přitom mnoho samostatných stromů, ve kterých fungují _různé_ věci a které spolu přátelsky soupeří.

A můj strom je jen jedním v tom lese.

Takže, není to chyba - je to ZÁMĚR!

Jako přípravu na záplavů testerů s blížícím se 2.6pre jsem se rozhodl tento dokument znovu vystavit, abych se ujistil, že v něm nic důležitého nechybí. (A navíc jsem chtěl už nějakou dobu poslat aktualizaci a 42 se zdálo být fajn číslo.)

Post-halloweenský dokument. v0.42
(aneb 2.5 - co nás čeká)
 
Dave Jones <davej@codemonkey.org.uk>
 
(Aktualizováno na základě 2.5.75)

Tento dokument vysvětluje nové funkce linuxového kernelu 2.5, některé problémy, na které můžete narazit, a také poukazuje na několik nových vlastností, které by opravdu potřebovaly testovat. Je-li níže napsáno "kontaktujte foo@bar.com", znamená to, že byste také měli poslat cc: kopii na linux-kernel@vger.kernel.org.

Nejnovější verzi tohoto dokumentu můžete vždy nalézt na http://www.codemonkey.org.uk/post-halloween-2.5.txt

Děkuji mnoha (moc na to, aby tu byl seznam) lidem za cenné připomínky.

Berte v úvahu, že tento dokument je trochu x86-středný, ale většina popisovaných funkcí se týká všech platforem.

Aplikace patchů.

• Ve 2.4 a předchozích jádrech bylo doporučovaným způsobem aplikace patchů použití příkazu...
  gzip -cd patchXX.gz | patch -p0
  Ve 2.5 začal Linus do diffů přidávat kousek cesty navíc, takže v rozbaleném adresáři, který má být opatchován, je třeba použít -p1.

Známé chybky.

Určité známé chyby jsou hlášeny stále dokola. Tady jsou postupy, jak je obejít.

• Prázdná obrazovka po dekomprimaci kernelu? Pamatujte na nastavení následujících věcí v souboru .config
  CONFIG_INPUT=y, CONFIG_VT=y, CONFIG_VGA_CONSOLE=y a CONFIG_VT_CONSOLE=y
  Mnoho lidí přišlo na to, že když vezmou svůj starý .config a spustí make oldconfig, aby přidali nové parametry, vede to k problémům - hlavně s tím, že není nastaveno CONFIG_VT.
• Další chyba, která trápí některé lidi, je neschopnost NIC (síťové karty) přijímat pakety (často se to projeví tím, že NIC nedostává DHCP lease, ačkoliv jí ho server posílá). Většina lidí tento problém vyřeší nabootováním s "noapic" nebo "acpi=off", případně s kombinací obojího. Další zprávy o selhání by měl dostávat Jeff Garzik <jgarzik@pobox.com>.
• (Možná existuje spojitost s předchozí chybou) VIA APIC routing je v současné době nefunkční. Bootujte s 'noapic'.
• Nemůžete natáhnout žádné moduly? Potřebujete aktualizované nástroje (viz oddíl Moduly níže).

Moduly.

• Natahování modulů do jádra bylo reimplementováno.
• Budete potřebovat náhradu za modulové utility z linux/kernel/people/rusty/modules/
• Sada zpětně kompatibilních modulových utilit je na stejné adrese k dispozici v RPM formátu.
• Uživatelé Debianu sid mohou 'apt-get install module-init-tools'
• Moduly teď uvolňují věci označené __init nebo __initdata.

• Pro uživatele RedHatu bude další problém v "/etc/rc.sysinit". Během startu nastaví skript binárku používanou k dynamickému natahování modulů uloženou v "/proc/sys/kernel/modprobe". initscript hledá "/proc/ksyms", ale protože v 2.5 kernelech neexistuje, použije se místo toho binárka "/sbin/true".

  To nakonec způsobí, že moduly nebudou fungovat. Uživatelé RedHatu budou muset opatchovat skript "/etc/rc.sysinit", aby nastavil "/proc/sys/kernel/modprobe" na "/sbin/modprobe", i když "/proc/ksyms" neexistuje.

Build systém kernelu.

• Build systém je ve srovnání s 2.4 hodně vylepšený. Buildy by měly být rychlejší a spontánní opětovné buildy souborů při pozdějších buildech v již sestavených stromech by měly být méně časté.
• Máme nové grafické konfigurační nástroje.
  "make xconfig" teď vyžaduje Qt knihovny.
  "make gconfig" používá Gtk knihovny.
• Make menuconfig/oldconfig nedoznalo žádných uživatelsky viditelných změn kromě rychlosti, ale přesto bylo provedeno mnoho vylepšení.
• Existuje několik nových build cílů: 'allyesconfig' 'allnoconfig' 'allmodconfig'.
• Poznámka: Nový konfigurační systém se netýká CML2.
• Také si povšimněte, že ačkoliv z něj byly převzaty nějaké nápady, nebyl integrován kbuild-2.5 projekt Keitha Owense.
• Preferovaným příkazem je teď "make" bez cíle; zkompiluje <arch-zimage> a moduly.
• "make -jN" je teď preferovaným způsobem pro paralelní spouštění make. Nemusíte se obtěžovat s "MAKE=xxx".
• Build je teď mnohem méně upovídaný. Pokud chcete přesně vědět, co se děje, zkuste "make V=1" nebo nastavte proměnnou prostředí KBUILD_VERBOSE=1.
• 'make kernel/mm.o' sestaví jmenovaný soubor - pokud existuje příslušný zdrojový kód. Funguje to i s (ne-kompozitními) moduly. (OPRAVA NUTNÁ: s moduly to teď nefunguje?)
• 'make kernel/' zkompiluje všechny soubory v podadresáři.
• Vůbec není potřeba spouštět 'make dep'.
• 'make help' vypíše seznam typických cílů, včetně debugovacích.

IO subsystém.

• Díky přepracování úrovní správy bloků a paměti byste měli oproti 2.4 zaznamenat nezanedbatelné zlepšení propustnosti.
• Všechny problémy z této oblasti hlaste těmto pánům: Jens Axboe <axboe@suse.de> a Andrew Morton <akpm@digeo.com>.
• Pomocí elvtune si můžete vybrat z několika dostupných IO elevatorů, které odpovídají různým druhům zátěže.
• Různé změny v blokové vrstvě znamenaly pro několik ovladačů blokových zařízení velké pročištění a aktualizaci na novější API.

Preemptivnost kernelu.

• Tolik probírané preemptivní patche se dostaly do 2.5. Měli byste si s nimi povšimnout o hodně menších zpoždění především v náročných multimediálních aplikacích.
• Vězte však, že jsou stále případy, kdy je třeba preemptivnost přechodně vypnout.
• Pokud se vám v syslogu objeví zpráva "xxx exited with preempt count=n", nepanikařte - nejsou závažné, jen trošku nejasné. (Něco si bere zámek, ale končí bez odemknutí.)
• Pokud přeci jen zaznamenáte u nějakého kódu vysokou latenci, oznamte to prosím na adresy Andrew Morton <akpm@digeo.com> a Robert Love <rml@tech9.net>. Zpráva by měla vypadat nějak takto "když provedu foo, dosahuje latence v mojí aplikaci xyz xxx ms, ale normálně je yyy", kde foo je akce typu "odlinkování velikého adresářového stromu".

PCI.

• Byla přidána podpora PCI domén. Pro většinu lidí to bude znamenat jen prodloužení názvů PCI slotů o "0000:" na začátku, ale pro lidi s většími servery to znamená, že budou mít možnost přistupovat ke všem svým PCI zařízením.
• Byly přidány další hotplug ovladače včetně falešného hotplug ovladače, takže lidi bez specializovaného hardware budou moci testovat funkce hotplug.

Vstupní vrstva.

• Možná nejviditelnější změna pro koncového uživatele. Pokud bude špatně nakonfigurována, nebudou vám klávesnice/myš/další vstupní zařízení fungovat. 2.5 nabízí pro zařízení jako klávesnice daleko flexibilnější rozhraní.

• Nevýhodou jsou další matoucí parametry. V menu "Input device support" určitě povolte alespoň následující.

  --- Input I/O drivers
  < > Serial i/o support
  < > i8042 PC Keyboard controller
  [ ] Keyboards
  [ ] Mice

  (Také ze seznamu vyberte odpovídající klávesnic/myš.)

• Pokud zjistíte, že vaše klávesnice/myš stále nefunguje, editujte soubor drivers/input/serio/i8042.c a nahraďte #undef DEBUG za #define DEBUG.

  Při bootu byste teď měli vidět mnohem více informací pro debugování. Přepošlete tyto informace Vojtěchu Pavlikovi <vojtech@suse.cz>

• Pokud používáte KVM přepínač a narazíte na problém, zkuste bootovat s parametrem 'psmouse_noext'.
• Uživatelé multimediálních kláves si při práci bez X povšimnou změn v tom, jak s těmito klávesami kernel nakládá. Lidi, kteří upravují keymaps nebo keycodes pro 2.4 budou možná muset pro 2.5 provést nějaké změny.

ALSA.

• Advanced Linux Sound Architecture byla začleněna do 2.5. Poskytuje výrazně zlepšené funkce oproti starším OSS ovladačům, ale potřebuje nové uživatelské nástroje.
• Několik distribucí už nějakou dobu ALSU poskytuje, takže potřebné nástroje už možná máte. Pokud ne, najdete je nahttp://www.alsa-project.org/
• ALSA umí emulovat rozhraní OSS pomocí modulů snd_pcm_oss/snd_pcm_mixer. Pokud se z vaší karty nic neozývá, budete možná muset pomocí programu alsamixer vypnout funkci 'mute' na kanálech, které /dev/mixer nevidí.
• OSS ovladače jsou stále funkční a stále přítomné. Mnoho nových funkcí/oprav, které byly začleněny do 2.4, ještě do těchto ovladačů nebylo přidáno a stále není jasné, jestli v kernelu zůstanou ve finální 2.6/3.0 verzi. Dlouhodobým cílem je přesvědčit všechny o přechodu na (výrazně lepší) ALSU.

Vrstva ramebufferu.

• James Simmons během 2.5 vrstvu framebufferu/konzole dost předělal. Podpora některých karet stále pokulhává, ale fungovat by to mělo stejně jako předchozí verze.
• Podle toho, který používáte ovladač, se možná změnily boot parametry. Příkladem takové změny je
  append = "video=radeon:1024x768-24@100"
  které teď musí být
  append = "video=radeonfb:1024x768-24@100"
• Stávající uživatelské nástroje (např. fbset) ještě nejsou aktualizovány, takže nebudou fungovat tak, jak byste čekali.
• VESA framebuffer nyní během inicializace umožňuje MTRR pro paměťový rozsah framebufferu (Poznámka: pouze PCI karty). Pokud budete mít rozházenou obrazovku, nahlaste to prosím spolu s výpisem lspci, aby mohla být vaše karta přidána na blacklist.
• Všechny problémy by měly být směřovány na <jsimmons@infradead.org>

v4l2.

• video4linux API se konečně dočkalo dlouho očekávaného pročištění.
• xawtv, bttv a většina dalších existujících v4l nástrojů jsou s novou v4l2 vrstvou kompatibilní, takže byste neměli zaznamenat jakoukoliv ztrátu funkčnosti.
• Více informací viz http://bytesex.org/v4l/.

Vypalování CD.

• Jens Axboe přidal možnost používání DMA při vypalování CD na ATAPI zařízeních. Zapisování CD by mělo být o hodně rychlejší než s 2.4 a také méně náchylné k podtečení bufferu a podobným věcem.
• Aktualizovaný cdrecord v rpm a tar.gz najdete v linux/kernel/people/axboe/tools/
• S těmito nástroji už také nepotřebujete ide-scsi, abyste mohli používat IDE CD vypalovačku.
• Ripování audio stop CD teď také využívá DMA a mělo by být o poznání rychlejší. Aktualizované cdda2wav najdete na stejném místě.
• Posílejte Jensi Axboeovi <axboe@suse.de> zprávy o ripování audia s cdda2wav a o vypalování s upraveným cdrecord.
• V současné době v cdrecord funguje pouze 'open by device name' (otevřít podle názvu zařízení).
  cdrecord -dev=/dev/hdX -inq
• Více informací na http://lwn.net/Articles/13538/ & http://lwn.net/Articles/13160/

devfs.

• devfs bylo poněkud ořezáno a bylo odstraněno mnoho duplicitních funkcí. Je třeba povolit CONFIG_DEVPTS_FS=y a připojit devpts filesystém stejným způsobem jako byste devfs nepoužívali.

sysfs.

Jednoduše řečeno, sysfs filesystém představuje pro ovladače rozumnější způsob exportu svých vnitřností než /proc. Tento filesystém je vždy zakompilován a může být připojen jako každý jiný virtuální filesystém. Nejsou potřeba jiné uživatelské nástroje než cat a echo.

mount -t sysfs none /sys

Více informací viz Documentation/filesystems/sysfs.txt.

Otázka kompilátoru.

• Doporučovaným kompilátorem (pro x86) je i nadále 2.95.3.
• Při kompilaci s moderním gcc (tj. gcc 3.x), 2.5 využije narozdíl od 2.4 dalších optimalizací. To může vynést na povrch chyby kompilátoru, které se u 2.4 neprojevily.
• Na x86 nepoužívejte kvůli chybě v manipulaci se stack ukazatelem gcc 3.0.x.
• gcc 2.96 není s CONFIG_FRAME_POINTER=y podporováno opět kvůli chybě v manipulaci se stack ukazatelem.
• gcc 3.2.2-5 dodávaný RedHatem vytvoří chybný kód v optimalizaci kmalloc zavedené od 2.5.71. Viz linux-2.5/cset@1.1410

Jména by vám měla být povědomá - je to stejné jako s 2.4.0.

Jedním rozdílem je, že zatímco 2.4.0 trvalo od pre1 do finální verze 7 měsíců, doufám (a věřím), že s 2.6.0 budeme mít méně problémů. Ale je nanejvýš zřejmé, že několik testovacích verzí před tou hlavní bude.

Pointou těchto testovacích verzí je, aby si lidi uvědomili, že je potřeba je testovat a aby si někteří bránící se vývojáři uvědomili, že na dělání vrásek kvůli další velké funkci je už pozdě. Doufám, že distřibutoři Linuxu začnou testovací verze nabízet jako instalační alternativy a také provedou upgrade interních strojů, takže až přijde 2.6.0, bude už vše hotovo.

Upřímně řečeno, než dám podporu pro XBox do standardního kernelu, chtěl bych, aby to začalo být daleko víc běžně používané.

Proč? Prostě proto, že zatím je to docela specializovaná věc, a tím pádem musím srovnávat užitek, který by začlenění do standardního kernelu přineslo, s negativním jevem - byli bychom trošku politicky "horkým bramborem".

Pochop mě: myslím si, že vytvoření portu pro XBox je fajn. Jenže dát to do hlavního stromu asi není dobrý nápad. Umím si lehce představit dost distributorů Linuxu, kteří nebudou mít pocít, že jim to za ty nervy stojí ;)

Oukej. Tak teď to vím, dík. Předpokládal jsem, že to bude buď takhle a nebo že to bude muset projít standardním postupem: tisíckrát poslat patch do lkml [Linux Kernel Mailing List] než bude přijat.

(A co se týče distribucí: Distributoři by klidně mohli v rámci aplikace všech svých patchů tuhle část vyhodit ;). A vím, že alespoň Mandrake se na XBox distro dívá pozitivně. A vývojáři Mandraku mi obzvlášť pomohli portováním jejich instalátoru, aby byl kompatibilní s XBoxem.)

Jen aby to bylo jasné: Tento patch neprovádí nic, co by se týkalo ochrany proti kopírování. Dokonce ani odemknutí harddisku. Je určen pro ty, kdo nahradí BIOS v XBoxu čistým, nemicrosoftím cromwell BIOSem, který má jediný účel - bootovat Linux.