AbcLinuxu:/ Články / Jaderné noviny 255

Štítky: AMD, ATI, audio, bezpečnost, Bluetooth, BSD, Ethernet, FreeBSD, FUSE, GNU, grafické karty, hardware, HTML, Intel, KDE, kernel, komunikace, Linux, patch, procesory, programování, rádio, reiser4, SELinux, sítě, souborové systémy, textové editory, udev, Vim, web

Jaderné noviny 255

2. 4. 2004 | Robert Krátký | Jaderné noviny | 4890×

Testovací nástroj Strace. Použití zvukových karet pro běžné datové přenosy. Intel vs. AMD x86-64. Patch pro podporu UFS2 (a UFS1). Výměna linuxového jádra za běhu. Stav pmdisk; uvažuje se o odstranění.

Do konference přišlo celkem 4058 emailů, nejvíce jich poslali Andrew Morton, Greg KH a Linus Torvalds.

Testovací nástroj Strace, 8 e-mailů

15. úno - 19. úno

Dan Carpenter napsal:

Je mi potěšením, že mohu oznámit první veřejné vydání Strace Testu. Jsem přesvědčen, že Strace Test je nejagresívnější obecný testovací nástroj, který je k dispozici. Strace Test většinou shodí můj systém během 5 minut (2.6.1-rc2).

Strace Test používá upravenou verzi strace 4.5.1. Namísto vypisování informací o systémových voláních volá upravená verze systémová volání s nesprávnými hodnotami. Patch a binárka pro i386 jsou součástí balíku strace_test.

Pro generování skutečných systémových volání využívá Strace Test LTP. Stačí rozbalit ltp a zadat 'make -k'. Test nemusíte instalovat.

Úpravy způsobí, že testovací skripty se zblázní. Abychom test udrželi tam, kde chceme, každých 10 minut je restartován. První skript je spuštěn pod rootem a samotný test je spuštěn pod testovacím uživatelem. Každých 10 minut odstřelí root všechny procesy testovacího uživatele a test restartuje. Vlastní testy jsou spouštěny s právy uživatele.

Strace Test najdete na: strace_test.tar.bz2

Pokyny k testování (pro i386)
Vytvořte testovacího uživatele
Stáhněte a rozbalte ltp (ltp.sf.net)
cd do ltp a `make -k`
Rozbalte strace_test
cd strace_test && ./go_go.sh
Zadejte cestu k ltp
Zadejte testovacího uživatele

Na Antona Blancharda a Roberta Williamsona to udělalo velký dojem a David Weinehall se zeptal: Pěkně prosím, nemohl bys takto zátěžově otestovat jádro 2.0.40 a výsledky mi nahlásit? Ačkoliv nečekám, že by 2.0-kernel byl zosobněnou stabilitou, bylo by fajn opravit všechny jasné chyby...

Použití zvukových karet pro běžné datové přenosy, 5 e-mailů

16. úno - 20. úno

Nischal Saxena se zeptal, jestli je možné přenášet data mezi dvěma systémy pomocí zvukových karet. Jamie Lokier odpověděl: Je to možné pomocí softwarového modemu, ale použít síťovou kartu je mnohem snazší :). Paulo Marques přidal:

Protože Nischal nespecifikoval, který port na zvukovce má na mysli, napadlo mě, že nejlepších výsledků by se dosáhlo s digitálním výstupem/vstupem SPDIF:

6 kanálů, 16 bitů, 48KHz = 4.6Mbit/s

Nevím toho dost o standardním digitálním formátu, ani o maximální šířce pásma, která by šla u zvukové karty využít, ale teoreticky bychom asi mohli propojit digitální vstup na jedné kartě s digitálním výstupem na kartě druhé a namapovat to celé jako síťové rozhraní :).

Každopádně je tohle naprosto bláznivý projekt, který by byl jen ztrátou času, protože ceny ethernetových síťových karet jsou dnes hrozně nízké.

Na jiném místě Pavel Machek poznamenal: Kdysi jsem data přenášel pomocí dtmf a dtmf dekodéru (PC pípátko na interní mikrofon notebooku), ale s pokročilejším softwarem by šlo dosáhnout daleko lepších rychlostí. Michael Clark odpověděl: Myslím, že už se na tom pracuje (jako součást GNU radio project): http://www.gnu.org/software/gnuradio/gnuradio.html

Intel vs. AMD x86-64, 99 e-mailů

17. úno - 26. úno

Linus Torvalds napsal:

Teď když Intel konečně kápnul božskou o své implementaci x86-64 (viz zde pro podrobnosti), mohl by někdo sepsat seznam rozdílů? Vím, že jsou lidé, kteří k těm dokumentům od Intelu měli přístup už nějakou chvíli, ale Intel je samozřejmě příliš nafoukanej, než aby ty rozdíly vyjmenoval rovnou.

Na první pohled to vypadá, že jde vlastně jen o 3DNow vs. SSE3, ale předpokládám, že i jiné detaily se liší.

(A tuším, že už je někdo i nachystaný s patchi...)

Mikael Pettersson napsal:

Z toho, co vyčtu z těch dokumentů mám pocit, že intelácké "IA-32e" je velmi podobné přirozené kombinaci P4 a AMD64. Žádné hyperlinkování, ale jinak stejné. Lokální APIC a počítače výkonu by měly být úplně stejné jako v P4 :-) .

A co pojmenování? IA-64 je už zabrané, AMD64 je příliš specifické, intelácké "IA-32e" zní neurčitě a x86-64 / x86_64 se mi těžko píše. Takže třeba "x64"?

Diego Calleja Garcia se zeptal: Znamená to, že distra založená na Opteronu budou moci běžet se svými x86-64 kernely/programy na inteláckých procesorech bez úprav? A Bryan O'Sullivan odpověděl: Pravděpodobně bude potřeba mírně upravit jádro, ale Intel tvrdí, že v budoucnu by měl být potřeba jen jeden 64-bitový kernel i aplikace pro obě platformy.

Ohledně pojmenování napsal Aaron Lehmann: Řekl bych, že se hodí AMD64. O všech AMD/Cyrix chipech jsme říkali, že jsou to IA32 procesory a tohle není v ničem jiné. Ale Mikael odpověděl: Já bych jim říkal x86, nikdy IA32.

A Linus řekl:

Bude to x86-64. Všechny ty hovadiny kolem "ia32" byly vždy trapné - nikdo nikdy neříkal x86 jinak než x86 a Intel to ještě zhoršuje tím, že na konec přidává náhodná a nelogická písmena.

Oproti tomu x86-64 ti přesne řekne, o čem je řeč. Navíc kernel té architektuře vždycky říkal takhle.

Popravdě jsem docela znechucený, že Intel ve své dokumentaci a zprávách AMD ani nezmínil. Takže bych to nejradši pojmenoval "AMD64", jen abychom přiznali zásluhy těm, kterým patří, ale nestojí to za tu námahu a zmatky.

Jsou-li v této konference lidi z Intelu, řekněte se svým šéfům, ať se kruci stydí. To, že se Intel nezajímal o své zákazníky a hrál si s nějakou 64-bitovou architekturou, kterou nechtěl nikdo používat, není omluva pro nepřiznání zásluh AMD za to, co s x86-64 udělali.

Patch pro podporu UFS2 (a UFS1), 4 e-maily

18. úno - 19. úno

Niraj Kumar napsal Andrew Mortonovi:

Prosím, začleň tento patch. Poskytuje základní minimální podporu pro read-only přístup k UFS2 variantě (z FreeBSD 5.x ) UFS filesystému.

Patch pro 2.6.3 je zde:
ufs2-read-only-p1.txt
ufs2-read-only-p2.txt

Andrew odpověděl:

Koukám, že tam máš mkfs.ufs. Takže to podporuje i UFS1?

Podporuje současný UFS little-endian stroje? Pokud ano, byl tento kód na nějakém testován? Ten kód vypadá dobře, ale testovat se musí...

Byl ten opatchovaný filesystém zpětně testovaný na UFS1?

Niraj potvrdil, že jeho patch skutečně UFS1 podporuje. Doplnil, že zpětné testování bylo minimální: Jen nějaké základní funkce (mount, read)..

Výměna linuxového jádra za běhu, 9 e-mailů

19. úno - 20. úno

Carlos Silva se zeptal, jestli je možné vyměnit kernel běžícího systému bez restartu. Jim Richardson navrhl: Mohl bys použít MkLinux (existuje to ještě?). Vzpomínám-li si dobře, tak ten umí spustit více jader najednou, takže pak bys mohl nové procesy postupně přesouvat na nový kernel a nakonec ukončit ten starý. Carlos tím byl nadšený a Jim dodal:

Nemám tušení, jestli to stále ještě někdo vyvíjí. Abych to upřesnil: není možné prostě prohodit jádra, ale přidat druhé a případně začít s přesunem úloh na něj.

Skoro totéž lze udělat i s User Mode Linuxem. Opět to není doslova výměna kernelu, ale tak trochu něco podobného.

Stav pmdisk; uvažuje se o odstranění, 41 e-mailů

28. úno - 02. bře

Pavel Machek se zeptal: Vadilo by opravdu moc, kdybych zkusil vyhodit CONFIG_PM_DISK? Zdá se, že to nikdo nespravuje, ekvivalentní funkčnost poskytuje swsusp a pro uživatele je to matoucí... Benjamin Herrenschmidt a další měli pocit, že by dávalo smysl ten kód v jádře zachovat, ale když se ho Pavel zeptal, jestli by jej byl ochoten spravovat, řekl, že ne. Pavel odpověděl: No, pokud se toho někdo neujme, nechám to prostě vyhnít a až to bude dostatečně nefunkční, pokusím se to odstranit. Opravdu nemám čas spravovat dvě implementace...

Jinde Karol Kozimor o CONFIG_PM_DISK řekl: Možná to není pěkné, možná to nikdo nespravuje, ale mám dojem, že některým lidem to funguje tam, kde swsusp ne. Takže pokud nebude každému fungovat swsusp nebo dokud nebude začleněno Nigelovo swsusp2, ponechal bych to tam. Pavel se zeptal na více informací o situacích, ve kterých pmdisk funguje, zatímco swsusp ne. Několik lidí se podělilo o své zkušenosti, ačkoliv bylo jasné, že ani jeden mechanismus není dokonalý.

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