Jaderné noviny 251

Podpora pro infračervené ovladače. KGDB. C++ moduly a kód kernelu. Diskuze o správcovství a přijímání patchů. ALSA versus OSS. Stav HPT370 v 2.4 a 2.6. Předběžná podpora AGPGART pro SiS648.

Pozn.: Vzhledem k nadstandardnímu rozsahu Kernel Traffic 251 jsem Jaderné noviny 251 rozdělil na dvě části.

Do konference přišlo celkem 2581 emailů, nejvíce jich poslali Andrew Morton, Rusty Russell a Pavel Machek.

Podpora pro infračervené ovladače v 2.4 a 2.6, 11 e-mailů

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, 33 e-mailů

KGDB 2.0.3 je k dispozici na 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.

C++ moduly a kód kernelu, 25 e-mailů

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.

Diskuze o správcovství a přijímání patchů, 18 e-mailů

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 osobou, 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ší.

ALSA versus OSS, 32 e-mailů

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.

Stav HPT370 v 2.4 a 2.6, 9 e-mailů

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á podpora AGPGART pro SiS648, 1 e-mail

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.

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

Diskuse k tomuto článku

V části Diskuze o správcovství, téměř na konci: Je v tom i dobrý pocit, ale

Ale co?

O kousek nad tím: Správce je osoubou

27.2.2004 10:28 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše chybky

Překlep jsem opravil, díky.

Co se týče toho "ale" na konci věty... Linus to tak skutečně napsal. Pravděpodobně tím myslel, že to má svá "ale" -- pouze už je nespecifikoval. Resp. jsou tím myšlena ta "ale" vyjmenovaná v jeho příspěvku. Doplnil jsem tam tedy tři tečky, aby to nemátlo.

Jaderné noviny 251 - I