Kernel Traffic #251 For 9 Feb 2004

There were 685 different contributors. 355 posted more than once. 279 posted last week too.

Gerd Knorr napsal: "Tento patch přidává modul s několika pomocnými funkcemi pro ovládání infračervených ovladačů pomocí linuxové vstupní vrstvy. Sám o sobě nic užitečného nedělá, ale ovladače saa7134 a bttv ho použijí k podpoře ovládačů dodávaných s některými TV kartami." Rusty Russell navrhl aktualizovat modul tak, aby používal nový kód module_param() z 2.6, ale Gerd řekl: "Ne. Modul, o kterém mluvíme, musí být možné zkompilovat i na jádrech 2.4, které nemají module_param(). A nechci kód zaneřádit mnoha #ifdef, pokud to nebude naprosto nutné. Udělám to pro IR podporu u bttv - ta je tak jako tak pouze pro 2.6, protože používá tasklety." Rusty řekl, že by to nevadilo; "Napíši a otestuji makra pro dopřednou kompatibilitu pro 2.4, pošlu je Marcelovi a pak budu znovu otravovat tebe 8)." O pár hodin později poslal patch pro kompatibilitu a dodal: "Nedělá to pole ani řetězce, ale kdyby byly potřeba, je možné je doplnit." Gerd napsal, že podpora polí bude v kódu jeho modulu, takže by bylo vhodné ji mít i v 2.4. Rustymu se moc nechtělo a diskuze se přesunula na soukromé maily.

KGDB 2.0.3 je k dispozici na http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernetové rozhraní stále nefunguje. Reaguje gdb na několik paketů a "zpanikaří" [panics ;-)].

Andi Kleen se zeptal, jestli Amit použil poslední netpoll patche a Amit odpověděl: "Netpoll (zatím) nepoužívám. Můj patch nevyžaduje žádné úpravy ovladače, které potřeboval mm ethernetový patch." Pavel Machek se zeptal, jestli to znamená, že nakonec Amit netpoll používat bude, a Amit řekl: "Ještě nevím. Nelíbí se mi představa, že by debugger používal hodně kódu jádra. Snažím se kgdboe implementovat bez netpoll a beze změn v ethernových ovladačích. Možná nakonec netpoll použít budu muset." Poblíž poznamenal Matt Mackall: "Původně jsem šel také cestou nemodifikovaných ovladačů, ale dlouhá diskuze s Jeffem Garzikem mě přesvědčila, že to byla chyba."

Někdo měl potíže s portováním C++ modulu z jádra 2.4 na 2.6 a Richard B. Johnson řekl: "V kernelu není žádná runtime C++ podpora pro C++. Určitě to je modul a ne aplikace? Mnoho síťových procesů (démonů) jsou aplikace a nevyžadují znalost žádných vnitřností kernel - kromě toho, co poskytují běžné C/C++ include soubory." Bart Samwel potvrdil, že se skutečně jedná o modul a dodal: "Součástí je patch pro kernel, který umožňuje začlenit hlavičky kernelu do C++. Například mění asm :: na asm : : (všimněte si mezery, :: je v C++ operátor) a přejmenovává "struct namespace" na něco, co obsahuje méně klíčových slov C++. Ten modul také obsahuje kód pro základní runtime podporu C++, takže C++ poběží uvnitř kernelu. Mám obavy, že zkompilovat to pro 2.6 bude dost náročné -- kernel by potřeboval spoustu patchů, a to ještě pravděpodobně úplně jiných než jaké byly potřeba v případě 2.4. Zprovoznit build systém je to nejmenší." Richard měl pocit, že celá záležitost je ztrátou času a že C++ v kernelu nemá místo. "Příště to bude Visual BASIC a pak Java."

Bart odpověděl s tím, že autoři daného modulu zvolili C++ asi prostě proto, že byli přesvědčení, že nejlépe splní jejich požadavky pro úkol, který si stanovili. Sice by určitě mohli totéž udělat i v C, ale protože modul už existuje od dob 2.2, obsahuje stovky souborů a portovat ho do C by bylo přinejmenším stejně pracné jako přizpůsobit kernel, aby jej akceptoval v C++ podobě, nemá cenu uvažovat o proč, ale o jak.

V Linuxu jsme už jednou C++ zkusili, dávno v roce 1992.

Je to děs. Věřte mi, psát kernel v C++ je ZATRACENĚ BLBÝ NÁPAD.

Faktem je, že kompilátorům C++ se nedá věřit. V roce 1992 byly ještě horší, ale některé zásadní věci se nezměnily:

Celé ošetření výjimek v C++ je od základu špatné. A především pak pro kernely.
Jakýkoliv kompilátor nebo jazyk, který rád schovává věci jako alokace paměti, prostě není dobrou volbou pro kernel.
V C se dá psát objektově orientovaný kód (vhodné třeba pro souborové systémy, atd.) a vyhneš se tak C++.

Obecně bych řekl, že kdokoliv píše své jaderné moduly v C++...

si říká o problémy
je C++ fanatik, kterému nedochází, že vlastně stejně píše C
to dostal ve škole za úkol.

Xose Vazquez Perez řekl, že ovladač aic7xxx v kernelu o hodně zaostává za ovladačem, který vydává Adaptec. Přidal: "Vypadá to, že ovladač v kernelu je bez správce. Pokud ovšem někdo nezačne pracovat na tom, aby portoval opravy/funkce od Adaptecu." James Bottomley napsal: "Takhle bych to neviděl. V současné době je správcem Adaptec - pokud se toho formálně nevzdají." Justin T. Gibbs se zeptal: "Mohl by ses podělit o svou definici "správce"? Vím, že jsem správcem ovladačů distribuovaných ze své stránky, ale nemám pocit, že bych byl správcem ovladačů ve stromech 2.4.X, 2.5.X nebo 2.6.X." James odpověděl: "Správce je osoubou, která spolupracuje s kernelovou komunitou, aby udržovala ovladač (nebo subsystém, filesystém nebo cokoliv) v aktuálním stavu. Taková osoba může ale nemusí mít záznam v souboru MAINTAINERS."

Má správce právo vetovat změny, které mohou poškodit kód, který spravují? Jinými slovy, ty říkáš, že jsem správcem ovladačů ve stromu kernel.org. To však nestačilo k tomu, aby nebyly tyto ovladače změněny bez odpovídající kontroly. Tvoje poslední aktualizace zanechala ovladač aic79xx v horším stavu než byl předtím (podívej se na záznamy v changelogu u těch verzí, které přišly po té, co jsi importoval ty - to byl důvod, proč jsem tu konkrétní revizi neposílal). Ty ses ani neobtěžoval mě zeptat, jestli by bylo vhodné verzi 1.3.11 importovat. A proto říkám, že se necítím jako správce. Nedostává se mi adekvátní kontroly nad výsledným produktem, ale i tak bych měl být zodpovědný, pokud nefunguje.

>Linus Torvalds odpověděl, že ve skutečnosti nemá nikdo absolutní právo vetovat změny kódu. A pokračoval:

Ani já nevetuji změny, které prosazují ti správní lidé (moje motto: "každý se někdy mýlí: když si stěžuje dost lidí, mýlím se i já").

"Koncepčně vyšší" správci mají obyčejně přednost. Řekne-li Al Viro, že filesystém dělá něco špatně z hlediska VFS, pak je prostě filesystém špatný - ať správce souhlasí nebo ne. Protože potřeby VFS vrstvy přetrumfnou jakékoliv otázky nízkoúrovňového filesystému.

Ale možná nejdůležitější je (a je to i důvod, proč ani já nemám to právo, nehledě na to, jak vysoko mezi správci stojím), že nikdo nemá vetovací práva nad ničím. To nutí lidi k čestnosti: nikdo by si nikdy neměl myslet, že "má kontrolu" a že je nenahraditelný.

Jinými slovy: správcovství není vlastnictví. Je to dozor.

Výsledkem je: správcovství je drsná a většinou nevděčná práce. Nedává moc privilegií a největší efekt je, že si vám lidi stěžují na chyby. Je v tom i dobrý pocit, ale

A konečně: správcovství je hlavně o práci s lidmi. Trochu programování, ale lidi bývají důležitější.

Markus Hastbacka se zeptal, jaký je rozdíl mezi ALSA a OSS. A proč je ALSA výchozí volbou v 2.6. Řekl, že chápe některé šikovné vlastnosti ALSA, ale poznamenal, že mu neumožňuje otevřít dva zdroje zvuku najednou, např. XMMS a Quake 3. Raphael Rigo nedokázal odpovědět na větší z otázek, ale poskytl odkaz na instrukce k umožnění softwarového mixování s ALSA. Jaroslav Kysela Markusovi odpověděl: "Vypadá to, že nechápeš naše cíle. Podívej se, prosím, na naše stránky - http://www.alsa-project.org. Používáš-li audio zařízení pouze spotřebně, pak si pravděpodobně nevšimneš ničeho zvláštního." Ohledně otevírání více zvukových zdrojů Jaroslav dodal:

Neprovádíme to v kernelu. Implementovali jsme přímé mixování streamů v naší knihovně (uživ. prostor). Pokud tvoje aplikace používá ALSA API, nebo když přesměruješ OSS ioctl na ALSA knihovnu (naše aoss knihovna), můžeš si užívat více zvuků.

Samozřejmě, že je stále lepší používat hardware, který umí mixovat hardwarově. Je to stejný rozdíl jako mezi softwarovým a hardwarovým renderováním 3D.

Jan De Luyck se zeptal, jak použitelný je Hightpoint HPT370 ide "raid" řadič na Linuxu 2.4 a 2.6; Wilfried Weissmann odpověděl: "2.4 je v pohodě, pokud používáš ataraid kód. Mirrorování netoleruje chyby, takže to radši nepoužívej. RAID-0 a jbod jsou v pořádku. V současné době se dívám na 2.6. Asi pro nový kernel napíšu nějaký EVMS plugin. Dobré na tom je, že to bude fungovat i pro 2.4 kernely s EVMS patchi a zároveň získáme korektní řešení pro mirrorování bez námahy :)." Brian McGroarty řekl: "S 2.4 žádné problémy nemám. 2.6 rozpozná 374, který používá ovladač hpt366, jako 370. Ale nedá z něj k dispozici žádná zařízení (http://lkml.org/lkml/2004/1/16/18)." . Xavier Bestel potvrdil stejné chování na svém systému; Mans Rullgard ale hlásil, že jeho hpt374-deska funguje s 2.6 dobře.

Předběžná 648FX agp podpora.

Problém se zpožděním popsaný v http://www.ussg.iu.edu/hypermail/linux/kernel/0401.1/0053.html stále existuje. Dave: jak jsi pokročil s tím data sheetem?

agp3 specifikuje věci, které byly ponechány na implementátorech v předchozích verzích - proto ten nový soubor generic-agp3.c file. Kromě zmíněného problému to vypadá, že se chipset 648 drží specifikací.

Je-li to pravda i o ostatních chipsetech, pak by mohlo být možné z tohoto v budoucnu udělat výchozí agp3 ovladač...

Uživatelé ovladače fglrx by měli vypnout volbu internalagp.

Aktualizace ovladače SiS framebufferu pro vanilla 2.6.1.

Protože to nevypadá, že by měly být bdev věci někdy v dohledné době začleněny, udělal jsem tento patch pro vanilla 2.6.1.

Trochu jsem ztratil pojem o aktuálních pravidlech ohledně velikposti patchů, takže mě omluvte, pokud je to přes limit.

SiSFB je v současných jádrech 2.6.x prostě nefunkční. Tento patch aktualizuje sisfb na úroveň stávající vývojové verze, která je před kernelem napřed o nějakých 11 měsíců.

Aktualizace obsahuje

hodně oprav :-)
podporu nových chipsetů (661, 741, 760)
podporu nových video můstků (301C, 302ELV)
odstraněn všechen chybný fp kód
množství pročišťujících úprav (což je hlavní příčinou velikosti patche)

Patch je zde: http://www.winischhofer.net/sis/sisfb_patch_2.6.1.diff.gz

Andrew Morton odpověděl: "Musíme to koordinovat s Jamesem a Benem, kteří rovněž pracují na věcech z této oblasti. Na druhou strany ten SiS patch nenecháme ležet, dokud nebude všechno kolem fbdev vyřešeno - život je příliš krátký ;)" . Thomas reagoval:

Přesně. Konference fbdevel je už nějakou dobu tichá. Ani nevím, jaký je současný stav.

Každopádně pro vyřazení úprav, které potřebují současné Jamesovy věci, byly nutné jen dvě direktivy překladače. Nemělo by to být moc těžké.

Vydal jsem udev verze 014. Najdete na:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014.tar.gz

RPM balíčky pro Red Hat FC1 jsou zde:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014-1.i386.rpm
a zdrojové RPM zde:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014-1.src.rpm

udev uživatelům umožňuje využívat dynamický /dev a poskytuje možnost mít stálé názvy zařízení. Používá sysfs a /sbin/hotplug a běží výhradně v uživatelském prostoru. K provozu je nutný kernel 2.6 s povolenou volbou CONFIG_HOTPLUG. Další informace v udev FAQ:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

Máte-li otázky ohledně udev vs. devfs, podívejte se sem:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

Hlavní změny od verze 013:

Rychlost! Tato verze je o _hodně_ rychlejší než 013. Díky Ananthu Narayanovi za úpravy libsysfs (a patch pro udev), které to umožnily.
Nový program nazvaný udevinfo v adresáři extras/ pomáhá zjišťovat sysfs informace o konkrétním zařízení. Hodí se při psaní nových udev pravidel.
Modifikátor %D je pryč. Pokud jste jej používali pro získání názvů ála DevFS, budete muset přepsat svá pravidla (podrobnosti v příkladech v konferenci linux-hotplug-devel).
Spousta malých oprav a změn.

Ještě jednou děkuji všem, kdo mi do tohoto vydání poslali patche.

Mike Gabriel se zeptal, jestli někdo pracuje na podpoře pro chipset vt6410 IDE/RAID v Linuxu 2.6. Pak dodal: "Pokoušeli se dokonce ve VIA, ale hodí se to pouze pro systémy Red Hat 7.2, a proto je to vysoce specifické." Jeff Garzik řekl, že ve 2.6 by už podpora . Mike se tedy zeptal na jména konfiguračních voleb, protože se mu nedařilo je najít. A Jeff odpověděl: "CONFIG_BLK_DEV_GENERIC nebo CONFIG_SCSI_SATA_VIA by to měly spravit." Mike pokračoval: "Myslel jsem, že tyhle volby jsou pouze pro SATA. Já potřebuji tu IDE část řadiče. Nebo je podpora v těchto volbách?" A Jeff řekl: "PATA část je spravována přes CONFIG_IDE, ale drivers/ide/pci/via82cxxx.c možná bude potřebovat jedno nebo více jiných PCI id. Získáš je pomocí 'lspci -n'."

Nicklas Bondesson se zeptal: "Zajímalo by mě, jak to vypadá s implementací ATARAID (náhrady) v jádrech 2.6.x. Lze to udělat pomocí mapování zařízení [device mapping], ale myslím, že to není ten nejhezčí způsob." A Mike Fedyk odpověděl: "Hodně lidí by nesouhlasilo. Vlastně to vypadá tak, že MD bude sloučeno s DM, takže můžeš klidně začít používat DM i pro tohle."

Tento patch odstraňuje z jádra memblks... nepoužíváme je a NUMA API, které se je chystalo použít, když byly vyvinuty, už to nemá v plánu. Představují jen zbytečný kód... čas jít.

Trochu to vypadá, že ia64 používá něco se stejným názvem pro část svého paměťového layoutu, ale Jes Sorensen byl tak hodný a oddělil to od sebe. Jes provedl testy na ia64 a já to zkusil přeložit na každé konfiguraci v mé výbavě.

Matthew Dobson řekl: "Jsem ten nešťastník, který to tenkrát protlačil, a jako takový podporuji rozhodnutí memblks odstranit. Nikdy nedošlo k věcem, které jsem měl s memblks v plánu a Martin má pravdu v tom, že teď už jen zabírají místo. Adios memblks, skoro jsme vás ani nepoznali." A Yasunori Goto doplnil: "Také mám pocit, že s odstraněním musím souhlasit, protože můj názor je zatím jen koncept a nemám v ruce žádný patch. Kdyby byly memblks opět potřeba až budeme moci podporovat částečná selhání paměti, patch pošlu."

Připojuji aktuální verzi forcedeth, síťového ovladače pro chipsety nForce{,2,3}, které jsou teď docela běžné běžné. Doposud byla jediná podpora ve formě binárního ovladače od nVidia.

Ten ovladač byl testován více než 200 lidmi na chipsetech nForce1, nForce2 a nForce3 a už byl začleněn do 2.6. Předtím byl pár týdnů v -mm. V současné době nemáme žádná nevyřešená hlášení o chybách.

Jeff Garzik se ozval s kritikou, protože patch podle něj nebyl dostatečně připraven pro začlenění, a protože se s ním měli nejprve poradit. Carl-Daniel odpověděl: "Sorry. Protože jsem si nevšiml žádných patchů pro síťové ovladače, které by šly do 2.4.25-pre, usoudil jsem, že tvou prioritou je teď 2.6. Když se na to dívám zpětně, vypadá to, že mě zmátl ten skok z 2.4.24-pre na 2.4.25-pre a zapomněl jsem zkontrolovat pre-patche." Slíbil, že se polepší s koordinací.

Cooperative Linux je portem linuxového jádra, který umožňuje kooperativní běh pod jinými operačními systémy v ring0 bez hardwarové emulace. Je založen na velmi malých změnách v kódu architektury a téměř žádných změnách ve funkčnosti.

Prostě vám v praxi umožní spustit Linux na neupravených Windows 2000/XP (uživatel pouze spustí aplikaci) a může v důsledku přinést Linux většímu počtu desktopových uživatelů, které by ani nenapadlo používat dual-boot systém nebo živou distribuci jako je Knoppix.

Screenshot a další podrobnosti zde:

http://www.colinux.org

Naše motto je:

"Běží-li Linux na každé architektuře, proč by mu měl stát v cestě jiný operační systém?"

V diskuzi, která následovala, lidé přidávali své představy o tom, čeho by měl být podobný projekt schopen a zároveň se objevilo několik odkazů na jiné projekty, které vice či měně podobným způsobem řeší obdobné věci:


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	15 Jan 2004 - 21 Jan 2004	(11 posts)	Podpora pro infračervené ovladače v 2.4 a 2.6
2.	16 Jan 2004 - 23 Jan 2004	(33 posts)	KGDB 2.0.3
3.	16 Jan 2004 - 21 Jan 2004	(25 posts)	C++ moduly a kód kernelu
4.	16 Jan 2004 - 21 Jan 2004	(18 posts)	Diskuze o správcovství a přijímání patchů
5.	19 Jan 2004 - 24 Jan 2004	(32 posts)	ALSA versus OSS
6.	20 Jan 2004 - 21 Jan 2004	(9 posts)	Stav HPT370 v 2.4 a 2.6
7.	20 Jan 2004	(1 post)	Předběžná AGPGART podpora pro SiS648
8.	21 Jan 2004 - 22 Jan 2004	(6 posts)	Aktualizace SiSFB
9.	22 Jan 2004	(1 post)	udev 014
10.	22 Jan 2004 - 24 Jan 2004	(6 posts)	Podpora chipsetu VT6410 IDE/RAID
11.	22 Jan 2004	(2 posts)	Stav ATARAID ve 2.6
12.	22 Jan 2004 - 28 Jan 2004	(4 posts)	memblks opouští 2.6 strom
13.	24 Jan 2004	(14 posts)	Forcedeth pro 2.4
14.	25 Jan 2004 - 29 Jan 2004	(21 posts)	Cooperative Linux: spuštění Linuxu pod Windows a dalšími systémy

Kernel Traffic #251 For 9 Feb 2004

By Zack Brown

Translated By: Robert Krátký