. [Nebo to byla chyba? Zdá se nepravděpodobné, že by se do Linusova stromu dostalo kgdb bez pořádného flamu...] Tom Rini odpověděl: Podpora PPC32 KGDB je už v kernel.org dlouho. Na druhou stranu jsem rád, že se tam dostala podpora SH kgdb..Portál AbcLinuxu, 8. května 2025 07:05
Stav podpory KGDB ve 2.6. Nový skript kpatchup pro patchování jádra. Vyřešena dlouhodobá chyba s přetečením LBD. Podpora highmem emulace ve 2.6. Snaha prosadit KGDB do jádra.
Do konference přišlo celkem 1601 emailů, nejvíce jich poslali Andrew Morton, Benjamin Herrenschmidt a Mike Fedyk.
4. úno - 4. bře
Pavel Machek si všiml, že v Linusově stromě už je nějaká podpora kgdb - alespoň pro některé architektury - a zeptal se: To je skvělé, nemohli bychom mít i i386 kgdb? Nebo aspoň amd64 kgdb . [Nebo to byla chyba? Zdá se nepravděpodobné, že by se do Linusova stromu dostalo kgdb bez pořádného flamu...] Tom Rini odpověděl: Podpora PPC32 KGDB je už v kernel.org dlouho. Na druhou stranu jsem rád, že se tam dostala podpora SH kgdb..
Tom pokračoval: Amitova práce je na http://kgdb.sf.net/. A to, co jsem s tím dělal já, je na bk://ppc.bkbits.net/linux-2.6-kgdb a http://www.codemonkey.org.uk/projects/bitkeeper/kgdb.
Andrew Morton odpověděl na původní Pavlovu zprávu:
Mnoho architektur má v jádře podporu pro kgdb už dlouhou dobu. Jen ne jedna z těch tří, které používám :(.
Začlenění i386 kgdb bych nepodporoval, dokud nedojde k velkým čistkám, snížení počtu funkcí a promyšlení rozdělení na kousky týkající se architektury a toho ostatního. Je to dost práce.
Několik lidí začalo probírat, co všechno je ještě třeba udělat, než bude kgdb možné přidat do jádra. Také to vypadalo, že některé firmy by byly ochotny zaplatit, aby to už bylo. Andrew v jednu chvíli poznamenal: Hodně lidem na tom záleží a mají samozřejmě moji podporu.
2. bře - 4. bře
Matt Mackall napsal:
Toto je první vydání kpatchup, skriptu pro snadnou výměnu verzí kernelů pomocí patchů:
V současné době podporuje 2.4, 2.4-pre, 2.6, 2.6-pre, 2.6-bk, 2.6-mm, a 2.6-tiny.
Příklad použití:
$ head Makefile VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 2 EXTRAVERSION =-rc2 [...] $ kpatchup 2.6-mm 2.6.2-rc2 -> 2.6.4-rc1-mm1 Applying patch-2.6.2-rc2.bz2 -R Applying patch-2.6.2.bz2 Applying patch-2.6.3.bz2 Downloading patch-2.6.4-rc1.bz2... Applying patch-2.6.4-rc1.bz2 Downloading 2.6.4-rc1-mm1.bz2... Applying 2.6.4-rc1-mm1.bz2 $ head Makefile VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 4 EXTRAVERSION =-rc1-mm1 NAME=Feisty Dunnart [...] $ kpatchup -q 2.6.3-rc1 $ head Makefile VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 3 EXTRAVERSION =-rc1 NAME=Feisty Dunnart [...] $ kpatchup -s 2.6-bk 2.6.4-rc1-bk3 $ kpatchup -u 2.4-pre patch-2.4.26-pre1.bz2
Je to alfa vydání určené k experimentování. Postřehy a patche vítám. Stahujte odsud:
Zwane Mwaikambo měl velkou radost a napsal: Tohle nahradí ten ošklivý shellový skript, který jsem používal dříve. Hlavně to využiji při stahování a patchování stromů před importem do CVS. Rusty Russell byl také potěšen a nabídl své vlastní skripty pro případ, že by něco z nich stálo za využití. Dave Hansen byl se skriptem také spokojen, ale napsal:
Vypadá to, že nesprávně zachází s prázdnými adresáři. Vyzkoušel jsem následující příkaz dnes ráno a nepochodil. Myslím, že je to kvůli prázdnému adresáři http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/ - díky včerejšímu vydání 2.6.4-rc2. Pythonu moc nerozumím, ale to "return p[-1]" je tam jen proto, aby způsobilo tuto chybu? Nebylo by lepší, kdyby skript vypsal zprávu "no version of that patch right now" a hezky se ukončil?
[dave@nighthawk linux-2.6]$ kpatchup-0.02 2.6-bk
"Traceback (most recent call last):
File "/home/dave/bin/kpatchup-0.02", line 283, in ?
b = find_ver(args[0])
File "/home/dave/bin/kpatchup-0.02", line 240, in find_ver
return v[0](os.path.dirname(v[1]), v[2])
File "/home/dave/bin/kpatchup-0.02", line 147, in latest_dir
return p[-1]
IndexError: list index out of range
Tvůj skript, zkombinovaný s Rustyho latest-kernel-version, mi pak budou stačit ke štěstí.
Chvíli se řešily chyby až vlákno skončilo.
3. bře - 4. bře
Eric Sandeen napsal: Několik uživatelů XFS narazilo na tento problém při pokusu o použití 2.6 + CONFIG_LBD na IA32 strojích - mkfs.xfs následované xfs_repair selhávalo. Nejprve jsme si mysleli, že jde problém RAID/MD, ale je to obecnější. Chyba je v __block_write_full_page(). Přiložil patch upravující datové typy několika proměnných tak, aby nepřetékaly; a Andrew Morton řekl:
Výborně. Ten bug tam byl od samého počátku. CONFIG_LBD kvůli této chybě nemůže správně fungovat.
Dík.
Vlastně jsou v buffer.c další dva výskyty této chyby. Tohle by je mělo napravit.
Poslal patch s několika zbývajícími opravami a Eric Sandeen nabídl další pro jednu, kterou Andrew přehlédl.
7. bře
Pavel Machek se zeptal, jestli někdo nemá highmem emulaci pro jádra 2.6; Michael Frank a Marc-Christian Petersen nabídli své patche. Michael o tom svém řekl: Byl v -mm dokud jej Andrew nevyřadil kvůli problémům na SMP a NUMA a s ramdiskem. Ramdisk očekává, že bude na konci lowmem zóny, takže při současné implementaci nebude s tímto patchem fungovat (paměť je přesunuta do highmem zóny).
8. bře - 10. bře
Amit S. Kale napsal:
Připojuji kgdb pro hlavní jádro ve třech patchech. Je to lite (lehká) verze, kterou můžete získat na kgdb.sourceforge.net. Myslím, že všichni souhlasíme s touto lite verzí.
Podporuje základní debuggování architektury i386 a debuggování přes sériovou linku. Ty patche obsahují následující:
[1] core-lite.patch: kód nezávislý na architektuře
[2] i386-lite.patch: i386 kód
[3] 8250.patch: podpora pro obecný sériový ovladač
Andrew Morton poděkoval a zeptal se, co konkrétně ten patch kvalifikuje jako "lite", tedy, které funkce byly vynechány. Amit řekl:
Tohle jsou funkce přítomné pouze v plném kgdb:
Ukázalo se, že Andrew by v patchi chtěl téměř všechny tyto funkce: ale podle Amita by pak už patch asi nemohl zůstat tak čistý. Konkrétně Info Thready připadaly Andrewovi velmi důležité, ale Amit měl pocit, že právě tato funkce by patch pěkně zaneřádila, kdyby byla vložena zpět. Ale dodal, že se na to ještě podívá, když to tam Andrew tolik chce.
V originálu Kernel Traffic 256 vyšla navíc ještě tato témata:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.