Portál AbcLinuxu, 7. května 2025 22:28
Problémy s bránou BitKeeperu; záhadné zamrzání jádra. Vývojáři se obávají žaloby SCO a připravují se na nejhorší. Konfigurační volby pro různé problémové případy. Začlenění .config v binárce jádra. Linus mluví o vykázání z konference.
Do konference přišlo celkem 2201 emailů, nejvíce jich poslali Andrew Morton, Alan Cox, Greg KH.
Marcelo Tosatti oznámil 2.4.22-pre3 a Ben Collins si stěžoval, že číslo -pre verze není ve zdrojovém kódu správně zobrazeno. Marcelo řekl, že jemu se zdroje zdají označené dobře a Larry McVoy se zeptal, Hmm. Bene, podívej se na CVS strom znovu. Jseš si jistý, že tam ty tagy nejsou? Možná to zvoral konvertor. Ben odpověděl, V linux-2.4/ChangeSet,v se to jako tag neukazuje. Adrian Bunk připojil, -pre2 a -pre3 v /v2.4/testing/cset/ také chybí. Jeff Garzik potvrdil, že ať už je problém kdekoliv, Marcelo svůj strom označil správně.
O pár dní později Larry napsal, myslím, že jsem našel tu chybu - je v kódu, který sestavuje vícečetné sady změn do jednoho CVS checkinu. Vypadá to, že tagy jsou začleněny pouze pokud je tag na poslední sadě změn v řadě, místo aby je zaznamenal i pokud jsou na kterékoliv sadě změn z celé řady. Pracujeme na opravě. Ben poděkoval a vlákno tím skončilo.
Na jiném místě Jim Gifford oznámil pokračující problém, který má s řadou 2.4: zamrzání, přibližně po dvou dnech. 2.4.22-pre3 problém nevyřešilo, ačkoliv pádům se dá vyhnout spuštěním 'sync' každou hodinu. Marcelo a Alan požádali o více informací a společně vyloučili verze kompilátorů a vadnou paměť. Během několika dalších -pre verzí problém nezmizel. Marcelo si pak povšiml, že Jimův kernel nepocházel z čistých zdrojových kódů (Jim přidal několik patchů pro netfilter a megaraid) a požádal, jestli by Jim mohl zamrznutí reprodukovat i s oficálním kernelem. Ano, stále to tuhlo.
Andrea Arcangeli se zapojil s návrhem, aby Jim odstranil devfs a další moduly, které nejsou součástí hlavního stromu. Jim to provedl a s verzí -pre7 už zamrznutí nezopakoval. Zeptal se Marcela, jestli chce, aby zkusil další testy, ale Marcelo odpověděl, řekl bych, že většina z nás je už přesvědčena, že ta zamrzání byla způsobena přidaným kódem. Ale Jim zkusil jádro -pre6 a opět došlo k zatuhnutí. Napsal k tomu, zdá se, že problém napravilo něco v -pre7. Takže začal kus po kuse přidávat neoficiální kód do -pre7 a později do -pre8, aby zjistil, co způsobí problém. Nakonec měl pocit, že zúžil problém na nějaké netfilter záplaty, které aplikoval. Marc Heckmann, který se s podobným zamrzáním setkal na svém systému, poznamenal, každý, kdo měl tento problém, používal iptables.
Situace byla poměrně složitá a nikdo v konferenci nedošel k jasnému závěru. Ke konci diskuze Jim shrnul: Divné je, že lidé mají problém s různými moduly a je těžké přijít na to, co mají společného.
Robert L. Harris se chtěl připravit na nejhorší. Kdyby SCO vyhrálo svůj soudní spor a existovaly části Linuxu od 2.4 výše, které skutečně porušují jejich autorská práva, co by obnášel návrat k 2.2 a pokračování vývoje odtud? Mike Fedyk odpověděl:
Žádná podpora highmem,
Žádné žurnálovací filesystémy.
Žádný netfilter. Méně síťových funkcí. Tečka. (ethernetové mosty, atd.)
Pomalejší SMP
Nevím, jestli to není jen psychologický dojem, ale vždy když jsem na desktopu nabootoval 2.2, zdál se mi pomalejší.
J.W. Schultz navrhl, mohl bys začít s "Báječným světem Linuxu 2.4" Joe Praneviche. Bylo přidáno množství vylepšení a funkcí, ale každé shrnutí změn během 2.2 -> 2.4 by mělo prozradit, o co bys přišel při přechodu 2.4 -> 2.2.
Na jiném místě se Bernd Eckenfels zeptal, mimochodem, co se stane, pokud v jádře je nějaký SMP kód od IBM, který vlastní SCO? Není to otázkou dní jej odstranit? Musel by kdokoliv platit za předchozí používání takového kódu? Alan Cox odpověděl, Základní 2.2 SMP kód jsou věci, které jsem napsal já. Caldera (aka SCO) mi dokonce poskytla hardware a požádali mě, abych to napsal. Pozdější kód analyzátoru tabulky je od Intelu. Robert poznamenal, Škoda, že nemáš nic z toho co ti dali nebo co si vzali zpět a co by mohlo být použito proti nim. A Alan odpověděl, To je záležitost už dlouho archivovaných záznamů. A Robert napsal, No jo, ale pravděpodobně to nebude nic například z korespondence, ve které ti ty věci nabízeli, když jim dáš kopii své práce na SMP, která by taky mohla být pod GPL...
Adrian Bunk zaslal patch, díky kterému všechny nefunkční ovladače v 2.6-test závisejí na volbě CONFIG_BROKEN; a všechny ovladače nefungující na SMP pak na CONFIG_BROKEN_ON_SMP. Napsal, že jich možná pár přehlédl a dodal, že Alan Cox upřednostňuje "CONFIG_OBSOLETE" před "CONFIG_BROKEN", a že Alanův výběr mu nevadí, pokud bude jinak patch přijatelný. Riley Williams odpověděl (mírně přeformátováno autorem KT):
Podle mě mají BROKEN (nefunkční) a OBSOLETE (zastaralé) rozdílné významy a mělo by záležet na okolnostech, který výraz se použije. Tady je můj návrh na definici případů, které mohou nastat:
Osobně bych rád viděl CONFIG_ANTIQUE (výchozí stav "n") jako závislost pro všechny ovladače, které vyhovují uvedenému popisu - aby se při konfiguraci snížil počet irelevantních voleb.
John Bradford souhlasil, že "BROKEN" a "OBSOLETE" mají výrazně odlišný význam. Pro "CONFIG_OBSOLETE" by mělo být podmínkou pouze aby byla daná funkce později navržena na vyřazení. Není potřeba mít náhradu za předpokladu, že funkce skutečně definitivně půjde pryč. Nicméně měl dojem, že "CONFIG_ANTIQUE" už je přehnané. Bud něco funguje, nebo ne. Pokud to má být z jádra vyřazeno, pak "CONFIG_OBSOLETE" je dostačující. Pokud to funguje a nebude to vyřazeno, pak není důvod to nazývat "antique" (starobylé). Stejně tak CONFIG_BROKEN se mu zdálo zbytečné ať už by byly jakékoliv kompilační problémy nebo vyložená selhání. Namísto toho by mělo být CONFIG_BROKEN rezervováno pro případy, kdy se ovladač (třeba SCSI) zkompiluje úspěšně, ale za určitých (možná ojedinělých) okolností potichu ničí data. V takovém případě je nezbytné lidi varovat, že to nefunguje, protože to nemusí být na první pohled zřejmé a mohlo by to způsobit významnou ztrátu dat. Ale Adrian byl jiného názoru: Zapomínáš na důležitou věc: Pokud si _uživatel_ stabilního kernelu všimne, že "se to ani nezkompiluje", nebude mít dobrý pocit z kvality linuxového jádra. John odpověděl:
Nesouhlasím. Vydávané jádro je rozpracovaným dílem a věci v něm čas od času nefungují, což je součást vývojového procesu. Zkušení uživatelé si to uvědomí a nezkušeným uživatelům bych kompilaci vlastního kernelu stejně nedoporučoval, protože by jim mohly uniknout záplaty, včetně bezpečnostních a těch, které opravují chyby vedoucí ke ztrátě dat - prostě proto, že by si mysleli, že v hlavním kernelu už budou.
Kompilování vlastního kernelu z oficiálních jaderných stromů je stále něco, co by mělo být považováno za věc pro zkušené uživatele.
Kromě toho, co je horší? Možná ztráta dat nebo špatný dojem?
Adrian napsal, že ne-experti si kompilují vlastní kernely každou chvíli a že ke špatnému dojmu a ztrátě dat existuje třetí alternativa a sice to, co dělá patch: zakáže daný ovladač, takže se jej nikdo nemůže omylem pokusit použít. Pak se vlákno vytratilo, aniž by se došlo k nějakému závěru.
Tichý konec dlouhé kontroverze...
Sean Estabrooks si vzpomněl na nějakou diskuzi ohledně začlenění souboru .config do zkompilovaného kernelu. Zeptal se, jestli to bude skutečností a Alan Cox napsal, ikconfig Randy Dunlapa je už nějakou dobu v 2.4-ac a do 2.6 byl právě přijat. Můžeš začlenit .config do /proc, připojit to k binárce nebo vynechat. A Randy Dunlap Seanovi odpověděl:
Alan před pár dny poslal můj ikconfig patch Linusovi a teď je v 2.6.0-test-current ... až na jeho Kconfig část, kterou buď Alan nebo já brzy pošleme (pokud to už Alan neudělal).
Celý (částečně začleněný) patch je na
Obsahuje skript (extract-ikconfig) a malý program v C (binoffsets.c), které se používají k vytažení uloženého .config image.
Pro soubor .config také existuje CONFIG volba, aby byl dostupný v /proc.
Na jiném místě Diego Calleja Garcia citoval z textu v konfiguraci:
Tato volba umožňuje uložení kompletního souboru ".config", informací o kompilátoru použitém pro kompilaci jádra, jádře běžícím při kompilaci tohoto kernelu a verze jádra z Makefile do kernelu. Dokumentuje, které volby byly použity v běžícím kernelu nebo v kernelu na disku. Tyto informace mohou být z image souboru kernelu vytaženy pomocí skriptu scripts/extract-ikconfig a pak použity k překompilaci stávajícího kernelu nebo ke kompilaci jiného. Pokud to bylo povoleno, tak je možné z běžícího kernelu tyto informace získat přečtením /proc/ikconfig/config a /proc/ikconfig/built_with. /proc/ikconfig/config vypíše konfiguraci použitou při kompilaci jádra a /proc/ikconfig/built_with vypíše informace o kompilátoru a systému použitém pro kompilaci.
William Lee Irwin III potvrdil, že patch už je v Linusově BitKeeper stromu.
H-Peter Recktenwald byl vykázán z konference LKML a soukromě si postěžoval Linusi Torvaldsovi, kterého se ptal, proč byl vykázán. Linus odpověděl do konference:
Možná proto, že to nemá co dělat s kernelem?
Diskutovat o záležitostech kernelu je v konferenci o kernelu v pořádku. Ale bylo tu spousta off-topic flamů, řečnění a obecného šumu.
Až do té míry, že mnoho lidí už nemělo čas konferenci sledovat, protože velká část diskuzí se vůbec netýkala technické práce na kernelu.
Vzhledem k tomu, že některé z těchto řečí bývají začínány (a udržovány) lidmi, kteří se vlastně nikdy nezapojí do _skutečných_ diskuzí týkajících se kernelu, nabyl David dojmu, že jednou z možností je zařazení lidí, kteří opakovaně posílají věci, které se netýkají kenelu, na černou listinu.
Čas od času off-topic příspěvek nevadí, ale stále to není přijatelné.
Tolik řečeno, David není zrovna diplomat a mám tušení, že to celé mohlo být vyřešeno trošku více uhlazeně. Jedním méně nepříjemným způsobem může být neblokování zpráv, ale připsání "[OFF-TOPIC]" na začátek řádky předmětu. Pak by si takové zprávy mohli ostatní filtrovat. Nebo prostě příspěvky přesměrovat do jiné konference.
Nevím. A je mi to docela jedno - ale já nikdy nebyl správcem konference a vím zatraceně dobře, že nikdy být nechci. Ten kdo je správcem, ten stanovuje pravidla.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.