Jaderné noviny 302

7. 4. 2005 | Robert Krátký | Jaderné noviny | 4047×

Podpora procesorů GEODE v 2.6. Stav modulárních framebufferů. FUSE jde do 2.6. Nové schéma číslování jader - w.x.y.z. Linux 2.6.11.1; diskuze o protokolu.

Podpora procesorů GEODE v 2.6, 4 e-maily

27. úno - 3. bře

Kianusch Sayah Karadji napsal:

Tento malý patch zajišťuje podporu procesorů GEODE CPU v jádře 2.6.10.

Ty procesory lze nalézt především v embedded systémech... jedním z nejslavnějších kousků hardware, který je používá, je pravděpodobně Soekris net4801 (http://www.soekris.com).

Patch už nějakou dobu leží na mých stránkách (http://www.sk-tech.net/ support/soekris.html) - ale několik lidí mě požádalo, abych jej zkusil nechat začlenit do hlavního jádra.

Stav modulárních framebufferů, 18 e-mailů

28. úno - 5. bře

Adrian Bunk se zeptal:

Dává vůbec smysl mít modulární framebuffery?

OK, distribuce chtějí všechno modulární, ale framebufferové ovladače, na které jsem se díval, parsují své specifické parametry v *_setup funkcích jen v případě nemodulární podoby.

A většina framebufferů obsahuje funkci module_exit. Opravdu existuje nějaký případ, kdy by tohle dávalo smysl a zároveň fungovalo?

Jeff Garzik napsal, že se to liší případ od případu, ale David Vrabel řekl, že modulární framebuffery mají svůj smysl na embedded systémech, kde nemůžeš používat zobrazovací hardware (a tak bys chtěl ušetřit trochu paměti), ale kde je vhodnější mít jen jeden build jádra/modulů. A ještě dodal: Když nic jiného, tak se to hodí pro testování. Je sice pravda, že ovladač framebufferu pro Geode po odstranění z paměti nevrátí režim, ale protože softwarová VGA emulace má na Geodě daleko k dokonalosti (nikdy jsem nepřišel na to, co se stalo s kurzorem...), předpokládám, že lidi stejně nebudou používat vgacon, takže není co obnovovat.

Paul Mundt souhlasil s tím, že embedded systémy modulární framebuffery využívají, a dodal:

Nedávalo by moc smysl ponechávat ovladač neustále natažený, není-li zařízení používáno jako konzole a využije se jenom občas.

Rozumnější se mi zdá prostě opravit ovladače, které to neumí pořádně. Většina nefunkčních ovladačů se stejně zdá být zaměřena na x86, kde to je lidem asi jedno.

Nedávalo by to moc smysl na x86 distribucích, ale pro vývoj ovladače na sekundárním zařízení je to užitečné. Ale to je výjimečný případ.

FUSE jde do 2.6, 12 e-mailů

2. bře - 5. bře

Miklos Szeredi se zeptal, jestli by FUSE nemohl být začleněn do hlavního jádra, když už strávil dlouhou dobu v Andrewově -mm stromu. Andrew odpověděl:

Plánoval jsem, že FUSE pošlu do Linusova stromu během jednoho nebo dvou týdnů. FUSE a cpusets jsou dvě věci, které stojí za zmínění jako kandidáti na 2.6.12.

• crashdump se zdá neustále nedokončený.
• perfctr funguje dobře, ale je v patové situaci, protože je "podobný, ale trošku jiný" než perfmon na ia64 a možná se nebude hodit pro ppc64 (i když na téhle frontě je v poslední době klid).
• nfsacl by mělo být pro 2.6.12 OK, jestli to bude OK připadat Trondovi.
• cachefs je trochu zaseknutý, protože jde o hromadu komplexního kódu, kterou ale používá pouze afs. Napojení na NFS by pomohlo.
• dm multipath je pro 2.6.12 OK.
• Reiser4 tak jasný není. Až budou adresovány všechny komentáře testerů a začneme pozorovat zájem výrobců, pak možná.

Anton Altaparmakov poznamenal:

Já bych rozhodně hlasoval pro začlenění FUSE. I když má několik částí, které by mohly být vylepšeny, kód funguje dobře. Mnoho lidí už FUSE dost dlouho používá. My jej máme nasazený v produkčním prostředí na čtyřech serverech a 650 pracovních stanicích k poskytování "souborového systému s kouzelnými symlinky" (tj. symlink XYZ ukazuje na různá místa podle toho, který uživatel se dívá) a neměli jsme žádné potíže. Dělal jsem i další testy s vrstveným FS s pomocí FUSE a bylo to velmi stabilní (ale pomalejší než ty symlinky, což je důvod, proč jsme to řešení zvolili).

FUSE možná není dokonalý, ale upřímně - který kód je? A navíc, spousta kódu v jádře nefunguje (aspoň někomu), ale je tam - a FUSE funguje dobře...

Christoph Hellwig chtěl trochu více času, aby mohl kód zkontrolovat; Miklos s tím souhlasil. Vypadá to, že dříve nebo později se FUSE do 2.6 stromu dostane.

Nové schéma číslování jader - w.x.y.z, 37 e-mailů

3. bře - 7. bře

Rene Rebe poslal jednořádkovou opravu pro 2.6.11 a Jeff Garzik řekl, že by to byl dobrý kandidát pro vydání jádra 2.6.11.y. Greg KH odpověděl:

Ok, opravil jsem ten patch a aplikoval ho na lokální strom, který jsem založil za účelem odchytávání podobných věcí (dokud se Chrisem Wrightem nedohodneme, jak na celou věc půjdeme, tak ho najdete na bk://kernel.bkbits.net:gregkh/linux-2.6.11.y).

Klidně nám tedy začněte posílat podobné věci (založíme pro to i alias).

Pár lidí se o patch přetahovalo, objevily se různé verze a nikomu nebylo jasné, kterou by bylo nejlepší použít. Na scénu přišel i další patch, který řešil jiný problém, a Greg s Chrisem uvažovali, jestli jej do vydání 2.6.11.y také zařadit. Greg se nakonec rozhodl nový patch začlenit, ale Linus Torvalds namítl:

Myslím, že ten váš postup nefunguje. Nedali jste lidem čas si stěžovat. Takže jste aplikovali první jednoduchou RAID6 věc a ukázalo se, že to byla chyba.

Ty patche musí mít pravidlo jako třeba "existují mimo cucákův strom aspoň dva dny". A během té doby může kdokoliv hlasovat proti (což by je přesunulo do množiny nezačleňovaných, přičemž někdo jiný se může rozhodnout, že do jeho stromu se i tak hodí).

A kdyby po uplynutí dvou dnů neměly dostatek kladných hlasů, přesunuly by se do skupiny "spáčů", kde ještě mohou dostat šanci (tj. upomínka v příslušné konferenci o tom, že patch umírá). A jestli ani pak nedostanou dost hlasů, přesunou se do seznamu nezačleňovaných.

Greg s tím souhlasil a napsal: Ok, sedneme si nad tím s Chrisem v úterý. Počkám se začleňováním a vydávání čehokoliv, dokud nebudeme mít kompletně stanovena pravidla a funkční infrastrukturu.

Linux 2.6.11.1; diskuze o protokolu, 54 e-mailů

4. bře - 8. bře

Greg KH napsal:

Pro ty z vás, kteří se nebrodili tím mohutným vláknem "RFD: Kernel release numbering" na LKML a neví tedy, že budeme vydávat jádra 2.6.x.y, tady je shrnutí:

Několik $cucáků se rozhodlo, že zkusí spravovat jádra 2.6.x.y, která budou následovat vždy po vydání 2.6.x. Jádra budou obsahovat jen sadu (bezpečnostních) oprav, které musí splňovat přísná pravidla stanovená Linusem v:

http://article.gmane.org/gmane.linux.kernel/283396 [pozn. překl.: doporučuji, obsahuje také vysvětlení "cucáků"]

---------------

Vydal jsem patch 2.6.11.1:
kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz

Podrobný seznam změn v:
kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1

BitKeeper strom pro vydání 2.6.11.y je zde:
bk://linux-release.bkbits.net/linux-2.6.11

Několik lidí bylo bez sebe radostí. Další měli střízlivější komentáře. Ian Pilcher napsal: Čistě z hlediska zpracování by se mělo dbát na to, aby se vše, co jde do 2.6.X.Y (např. 2.6.11.1), dostalo i do 2.6.X+1 (např. 2.6.12). A Greg odpověděl: Tak se stane. A někde jinde v diskuzi Linus Torvalds řekl: Prostě si to stáhnu ze stromu těch cucáků.

---

V originálu Kernel Traffic 302 vyšla navíc ještě tato témata:

• Linux 2.6.11-rc4-mm1 Released
• New Digi Neo Serial Port Adapter Driver
• Linux 2.6.11-rc5-mm1 Released
• Improving The BitKeeper->CVS Gateway
• Kernel Crypto API Maintainership
• Guidelines For Accepting Patches Into The w.x.y.z Tree
• Video4Linux Maintainership
• Linux 2.4.30-pre3 Released

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

       

Komentáře