Portál AbcLinuxu, 7. května 2025 17:30
Linux 2.6.13-rc7. Nové testovací vydání SPUFS; diskuze o umístění v adresářové struktuře zdrojových kódů. Ovladač čidla zrychlení HDAPS; problémy s rozpoznáváním hardwaru. Ovladač pro MPC8xx PCMCIA si našel cestu do jádra 2.6. Monitorování využití jader mezi dobrovolníky.
23. srp - 29. srp
Linus Torvalds oznámil Linux 2.6.13-rc7:
Už jsem chtěl opravdu vydat 2.6.13, ale zatímco jsem čekal na vyjasnění dalších problémů, proběhlo dost změn, takže myslím, že bude lepší nechat ještě -rc7.
Většina změn v -rc7 je triviálních, buď jednořádkové opravy nebo se týkají nějakého konkrétního ovladače či neobvyklé konfigurace. Krátký seznam změn (připojen) by měl docela dobře osvětlit, o co šlo.
25. srp - 29. srp
Arnd Bergmann napsal:
Jde o pracovní verzi souborového systému SPU.
Od minulé verze bylo přidáno hodně funkcí a opraveno mnoho chyb. Máme už podporu pro read() souboru /run, aby bylo možné spouštět na SPU kód. Bylo přidáno několik souborů, které poskytují přístup k více hardwarovým funkcím, hlavně kanálům pro hlášení signálů [signal notification channels].
Ale především máme funkční ukládání a obnovování SPE, které napsal Mark Mutter. Výsledkem bude jaderný plánovač [scheduler] pro SPU. A protože to souborový systém dost nafouklo, rozděluji jej teď na více menších patchů.
Během následujících týdnů provedeme ve zdrojácích rozsáhlejší změny, takže tato verze je pravděpodobně poslední, která je binárně kompatibilní s předchozími.
Máte-li specifické požadavky, které spufs v současné podobě nesplňuje, je teď vhodná doba nám o nich dát vědět.
Pekka Enberg odpověděl: Jsem zmaten. Kód se liší na různých architekturách a provádí I/O na zařízení. Proč to chcete dávat do fs/ a ne drivers/? Arnd vysvětlil:
Nikdy jsem o tom nepřemýšlel jako o ovladači zařízení, ale spíš jako o rozšíření pro architekturu - proto byl kód původně v arch/ppc64/kernel. Vzhledem k tomu, že pracuje s VFS, je teď ve fs/spufs. Jinak mi ale na umístění nezáleží. Já bych navrhoval následující místa (řazeno od nejlepšího).
1) By bylo místo, kde bych chtěl stejně mít nízkoúrovňový kód (arch/ppc64/kernel/spu_base.c), takže dává smysl tam mít vše, co spravuji.
2) By mohlo být lepší, budeme-li mít v budoucnu v arch/powerpc více druhů platforem, které by používaly SPE. Např. pokud chceme podržet kód pro Playstation odděleně od obecného Cell.
Pekka odpověděl: Nemám nic proti 1, 2 a 4. Samozřejmě byste mohli abstrahovat části spufs, které slouží obecným účelům (kdybychom například měli podobná rozšíření architektur, která by mohla sdílet kód), a dát je do 3, ale to by asi způsobilo zbytečné komplikace.
26. srp - 30. srp
Robert Love napsal:
Pracuji na ovladači pro IBM Hard Drive Active Protection System (HDAPS), který poskytuje čidlo zrychlení ve dvou osách a různá další data. Ten hardware najdete v nových noteboocích IBM ThinkPad.
Brian Gerst se zeptal: Existuje nějaký způsob, jak zjistit, jestli je zařízení v systému (PCI, ACPI atd.), aniž by se zkoušely porty? Robert odpověděl: O žádném nevíme. Je to zařízení pro zastaralou platformu. Takže bohužel žádná probe() rutina. Arjan van de Ven navrhl: DMI určitě... Robert na to řekl, že rád přijme patche a Alan Cox napsal: Myslím, že by to před začleněním mělo být opraveno. Robert odpověděl:
Ujasněme si to. Existuje init rutina, která kontroluje přítomnost zařízení.
Jen není k dispozici rychlý, jednoduchý a neagresivní test.
Ovladač by se však určitě nenatáhl na notebooku bez potřebného hardwaru.
Dave Jones poznamenal: Zkoušení I/O portů kvůli hardware, když tam zařízení není, může být osudné. Co se stane, když budu mít na I/O portu 0x1600 něco úplně jiného? (A tak projdu tvým testem request_region()). accelerometer_init() pak začne vesele zkoušet porty a provádět všelijakou další černou magii.
A poblíž řekl Jeff Garzik o DMI: Protože je takový test možný, jde určitě o věc, kterou je třeba před začleněním napravit.. Robert odpověděl:
Zaprvé, já přeci Linuse nežádám, aby to začlenil. Všichni by se měli z hluboka nadechnout.
Zadruhé, nevíme, jestli bude řešení pomocí DMI fungovat. Vyzkouším to.
29. srp - 1. zář
Marcelo Tosatti napsal:
Posílám ovladač 8xx PCMCIA, který původně napsal Magnus Damm, s několika vylepšeními a opravami.
Ovladač byl začleněn do 2.4, ale nikdy nebyl portován na 2.6.
Prosím o kontrolu, uvítám komentáře (včetně estetických záležitostí).
Magnus Damm reagoval:
Je fajn, že byl ovladač portován na 2.6. Tenkrát jsem ho napsal pro pcmcia-cs, ale po čase se dostal do 2.4. Děkuji všem, kdo přidali kód a opravy.
Nevím moc dobře, jak funguje současná linuxová PCMCIA vrstva, a už se nezabývám PowerPC, takže samotný port komentovat nemohu.
29. srp - 1. zář
Andrea Arcangeli napsal:
Během Kernel Summitu někdo začal mluvit o tom, že není jasné, jak moc jsou jádra rc/pre/git testována před vydáním finální verze.
Připravil jsem tedy server, který automaticky sleduje, jak moc jsou jednotlivá jádra testována. Budou to samozřejmě velmi hrubé odhady a ani to nemůže být věrohodné, ale možná to bude užitečné. Pokud to bude k ničemu, tak se nic neděje, protože jsem s tím strávil jen chvíli ;).
Podrobnosti najdete na stránkách projektu:
Kompletní zdrojáky (včetně serveru) jsou zde:
http://klive.cpushare.com/downloads/klive-0.0.tar.bz2
Spuštění klienta:
wget http://klive.cpushare.com/klive.tac
Pak při každém bootu (třeba v /etc/init.d/boot.local):
twistd -oy klive.tac
Teoreticky bychom se klienta mohli zbavit úplně a udělat z toho konfigurační volbu do jádra. Ale nemám zdání, jestli půjde o užitečný projekt, takže se mi tomu nechce v tuhle chvíli věnovat příliš času.
Chvíli se diskutovalo o tom, jestli by to lidé neřadili do kategorie "spyware". A Alan Cox k tomu v jednu chvíli řekl, že by bylo nutné počítat se sbíráním údajů jen od lidí, kteří by to výslovně dovolili: Asi by to snížilo objem, ale zároveň zvýšilo kvalitu. Zvláště pokud by id z cookie mohlo být vloženo do bugzilly, a hlášení o hardware by bylo ve strojově zpracovatelném tvaru (takže by pak bylo možné ptát se např. takto: "spolehlivost s nVidia IDE"). A Sven Ladegast souhlasil: Změna zdrojových kódů jádra, díky které by byla automagicky odesílána data někam po síti, nemůže být ve výchozí konfiguraci povolena. A Alan dodal: Nepotřebujeme osobní údaje (email, jméno, ip, adresa atd.). Ale co by s tím šlo dělat, to by bylo opravdu zajímavé.
V originálu Kernel Traffic 326 vyšla navíc ještě tato témata:
Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.