Jaderné noviny 41

4. 2. 2002 | Leoš Literák | Jaderné noviny | 1191×

Další díl Jaderných novin.

Statistika za období 12.10. - 25.10.1999

1153 dopisů o celkové velikosti 4394 KB
446 různých autorů, z nichž 191 poslalo více než jeden dopis.
 

Nejaktivnější autoři

dopisů	KB	autor	email
83	231	Alan Cox	alan@lxorguk.ukuu.org.uk
32	151	Andrea Arcangeli	andrea@suse.de
30	118	Jeff Garzik	jgarzik@mandrakesoft.com
28	88	Tigran Aivazian	tigran@sco.COM
23	80	Alexander Viro	viro@math.psu.edu
21	73	Ingo Molna	mingo@chiara.csoma.elte.hu
20	70	Richard B. Johnson	root@chaos.analogic.com
16	86	Manfred Spraul	manfreds@colorfullife.com
16	71	Linus Torvalds	torvalds@transmeta.com

Nejzajímavější diskuse

1. Optimalizace pro http server
2. Bootsector a assembler
3. Pokrok ve velkých pamětech
4. OT: barvoslepost
5. Velká diskuse o způsobu vývoje jádra
6. Další konference o hardwaru
7. Vadná RAM
8. Non-GPL ovládače od Intelu

Optimalizace pro http server

12.-19.10.1999, 6 dopisů

Dan Kegel přišel se zajímavým problémem, na který narazil během snahy o nalezení nejefektivnějšího způsobu, jak zasílat soubory klientům skrze webový server. Pokud server vytvoří nové vlákno pro každý požadovaný soubor, na jedné straně klienti se nebudou zbytečně navzájem zdržovat během zpracování, na druhé straně se však zvýší režie při přepínání kontextu mezi vlákny. Druhou možností je, že http server bude používat volání systémové funkce sendfile() pro zpracování všech požadavků. Toto řešení ušetří režii během přepínání kontextu, ale bude blokovat ostatní čekající klienty. Pak navrhl optimalizaci funkce sendfile() tak, aby tato funkce četla z disku pouze ty soubory, které nejsou v paměti. V této souvislosti se zeptal, zda režie při čtení zbývajících souborů z disku bude menší než režie při přepínání kontextu. Rik van Riel navrhl použít asynchronní callbacky pro přesun této funkčnosti do "bottom-half". Stephen C. Tweedie poznamenal, že toto řešení není principiálně možné. Místo toho navrhl rezervovat malé množství vláken jádra pro tyto účely. Diskuse skončila poté, co Chuck Lever zaslal adresu článku, ve kterém autor navrhuje plánovací strategii, která upřednostňuje klienty s nejkratším řetězcem dat k odeslání.

Bootsector a assembler

15.-19.10.1999, 21 dopisů

Andrzej Krzysztofowicz se zeptal, proč se kód pro bootsector v i386 překládá do 32 bitů místo původního 16-bitového kódu. Podivoval se nad tím, neboť takto se zbytečně přidává byte ke každému příkazu v místech, kde je nutné pamětí šetřit. Autor kódu Chris Noe vysvětlil, že tyto změny byly nutné kvůli odstranění závislosti na as86 a ld86 a že umožnily použít gas místo as86. Bohužel v aktuální verzi gas nepodporuje 16-bitový kód. Také poznamenal, že samozřejmě plánuje optimalizaci pro 16-bitové assemblery a jakmile jádro bude vyžadovat binutils verze 2.9.5, celý kód opět přepíše. Albert D. Cahalan se však naštval, že Chris používá techniku špatných zdrojových kódů, které se ale kompilují do správného tvaru. Také Chrise podezříval, že zatajil tyto detaily před Linusem a že jeho patch vyžaduje nové verze překladačů. Chris odpověděl, že tato verze je již stejně vyžadována pro jádra 2.2.

Pokrok ve velkých pamětech

16.-21.10.1999, 5 dopisů

Linus oznámil, že uvažuje o přidání patchů pro Bigmem do oficiálních jader. S patchi, které zaslalo Ingo, může Linux podporovat až 64 GB RAM. V oznámení verze 2.2.13ac1 Alan přidal: "Bigmem do 4 GB je možné považovat za velmi stabilní. Ve skutečnosti věřím, že SUSE již dodalo tuto podporu ve verzi 6.2 (může to někdo ze SUSE potvrdit?). Bigmem nad 4 GB ale stabilní ještě není."

OT: barvoslepost

16.-22.10.1999, 22 dopisů

Riley Williams, správce serveru Linux Kernel Version History, obdržel několik dopisů od barvoslepých lidí, kteří mají potíže se čtením jeho stránek. O tyto dopisy však přišel během výpadku elektřiny a tak chtěl kontaktovat jejich autory touto cestou. Poznamenal, že sám je barvoslepý na červenou a zelenou barvu, takže asi není vhodnou osobou na vymýšlení barevných schémat. Proto požádal o zaslání navrhů, které splňují kritéria nezávislosti na prohlížeči a operačním systému. Audin Malmin navrhl použít světlý text na tmavém pozadí, neboť proč by mělo zářit pozadí, když text je důležitější. David Ford odpověděl, že je dokázáno, že se lidem lépe čte černý text na bílém pozadí než obráceně. Alexander Viro poznamenal, že z velké plochy blikajícího bílého pozadí bolí oči na běžných monitorech. Tim Towers přidal, že světlý text na tmavém pozadí se používá v terminálu, dosu a linuxové konzoli, kdežto grafické prostředí Xů a Windows používají opačný přístup. Důvodem má být grafická podobnost okna a listu papíru. A na papíře se používá černý inkoust, protože se snáze vyrábí než bílý inkoust.

Velká diskuse o způsobu vývoje jádra

19.-25.10.1999, 63 dopisů

Alan a Donald Becker diskutovali o Donaldově práci na PCI, když je přerušil Linus s kritikou způsobu, jakým Donald vyvíjí své ovladače. Řekl, že místo jednoho obrovského patche, ke kterému ostatní vývojáři nemají po dlouhou dobu přístup, preferuje postupný vývoj. Donald se ohradil, že jeho kód je veřejně přístupný na jeho stránce a diskutuje se o něm ve zvláštní konferenci. Také řekl, že se takto snaží minimalizovat počet oficiálních verzí. Navíc se podivil, proč se vůbec snaží, když všechna jeho práce je zavržena, zatímco cizí netestované patche Linus používá.

Linus odpověděl, že jeho poslední "testovaný patch" vůbec nefungoval na třech strojích, kde jej Linus zkoušel. Navíc se Linusovi nelíbilo, že mu Donald nezasílá své patche častěji a některé mu nezaslal několik let a jiné, jako třeba hledání PCI, Linusovi nezaslal vůbec. Proč se tedy [Donald] zlobí, když zařadí patch, který OBDRŽÍ. Donald na to řekl, že každý patch čtvrt až půl roku testuje, než jej zašle Linusovi. Tímto způsobem se snaží mu ušetřit práci. Pro vysvětlení způsobu vývoje jádra Linus napsal, že zásadně neprohledává internet, aby našel nějaké patche. Pokud je nedostane emailem, předpokládá, že je autor nechce zařadit do hlavního proudu vývoje. Pak řekl: "Například zásadně nepříjímám rozsáhlé patche. Zeptejte se Alana, který dělá zatraceně dobrou práci při správě velké části jádra (klobouk dolů) a pak také dělá zatraceně dobrou práci při dělení patchů do jejich původních tvarů." Pak popsal, že místo jednoho velkého ac patche obdrží padesát malých, z nichž 48 použije.

Donald si postěžoval, že na přání Linuse přepsal kus kódu a strávil nad tím několik týdnů, jenže Linus jej pak zavrhl. Linus opět odvětil, že tyto patche ani neobdržel, proto je ani nemohl zavrhnout. Do debaty vstoupil David S. Miller a pokusil se názorně na příkladě vysvětlit Donaldovi, proč se Linusovi jeho přístup nelíbí. Linus totiž potřebuje mít celou historii malých patchů řešících jen jeden problém, aby mohl snadněji nalézt případné chyby. Linus dodal: "Uvažujte o mně jako o CVS s mozkem a určitou chutí." Později ještě pro vysvětlení přidal: "Co by se stalo, kdyby všechny ovladače byly umístěny pouze na svých stránkách na internetu a každý uživatel si je musel stahovat pro svou kombinaci hardwaru a prohledat přitom pět různých serverů? Opravdu si myslíte, že takový systém může přežít a zvětšit počet svých uživatelů?"

Další konference o hardwaru

19.-20.10.1999, 15 dopisů

Rik van Rie oznámil vznik nové konference, kde se bude diskutovat o kompatibilitě hardwaru pod Linuxem. Chtěl tak omezit zasílání takových dopisů do konferencí linux-kernel a linux-smp [poznámka překladatele: z podobných důvodů vznikl server Linux Hardware v ČR :) ]. Ben Castricum podotkl, že toto bude místo, kam je možné někomu povědět, ať nekupuje desku ASUS MEW, neboť ani integrovaná zvuková karta AD1881, ani integrovaná grafická karta Intel 810 nejsou podporovány. Okamžitě se rozvinula diskuse, že to není tak zcela pravda a diskuse pak pokračovala na téma podpory Linuxu některými výrobci.

Vadná RAM

20.-22.10.1999, 8 dopisů

Miquel van Smoorenburg několikrát obdržel oops ve funkcích del_timer(), select_dcache() a find_buffer() v závislosti na tom, kterou verzi 2.2.13preX používal. Dalšího dne si sám odpověděl. Simon Kirby mu poslal malý prográmek, který nalezl vadnou paměť v jeho stroji. Miquel napsal malou poučku: "Pokud máte vadnou RAM, pravděpodobně skončíte oopsem ve find_buffer() nebo select_dcache(), asi je to symptom vhodný na zapamatování." Alexander Viro vysvětlil, že obě funkce často pracují s dlouhými seznamy.

Non-GPL ovládače od Intelu

22.-25.10.1999, 8 dopisů

Dan Browning poslal URL na ovladač pro Linux 2.2 pro Intel PRO/1000 Gigabit Server Adapter a zeptal se, kdy bude tento ovladač začleněn do jádra. Florian Lohoff podotkl, že nikdy, protože licencí není GPL a navíc licence ani není kompatibilní s GPL. Později Jes Sorensen poznamenal, že navíc tyto ovládače jsou špatně napsané a nikdo se je nesnažil udělat přenositelné na jiné platformy než x86. Pak ještě popsal několik programátorských prohřešků a udělal si legraci z toho, že ten adapter asi musí být hodně špatný, když programátor používá spinlock.

---

Tento článek je překladem serveru Kernel traffic a je zveřejněn pod licenci GPL verze 2. Přeložil Leoš Literák.        

Komentáře

[test]

test

[test2]

test2

[test3]

test3

[test4]

test4

[test5]

test5