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

Štítky: C, C++, GCC, hardware, kernel, kompilace, Linux, myš, ovladače, patch, PCI, programování, RAM, sběrnice

Jaderné noviny 285

6. 12. 2004 | Robert Krátký | Jaderné noviny | 4727×

Velká aktualizace sériového ovladače. Diskuze o důvodech pro podporu starých kompilátorů. Oprava pro myš na PC100.

Do konference přišlo celkem 1935 emailů, nejvíce jich poslali Greg KH, Adrian Bunk a Andrew Morton.

Velká aktualizace sériového ovladače, 9 e-mailů

31. říj - 4. lis

Russell King napsal:

Ok, tohle je zásadní aktualizace. Obsahuje:

register_serial/unregister_serial už se nepoužívá. Místo toho používejte ke komunikaci s ovladačem 8250 serial8250_register_port() a serial8250_unregister_port().

Stará rozhraní mají několik omezení:
1. Neumožňují struct device asociovanému s portem, aby o něm věděla tty vrstva.
2. Mají různá omezení velikosti IO adres (viz HIGH_BITS_OFFSET).
Poskytujeme mechanismus pro dynamickou registraci 8250 portů platformy. Děláme to přes zařízení platformy - buď jedno nebo více zařízení. Můžete mít nulu, jeden nebo kolik budete chtít. 8250.c je to úplně jedno.
Prozatím budou všechny porty vypsané v include/asm-*/serial.h i nadále inicializovány přednostně před porty zařízení platformy. Očekává se, že všichni začnou používat metodu zařízení platformy.
To znamená, že se mírně pozmění definice CONFIG_SERIAL_8250_NR_UARTS. Je to počet portů _navíc_ nad těmi v include/asm-*/serial.h, které bude 8250.h podporovat. Po odstranění všech portů z include/asm-*/serial.h je to samozřejmě celkový počet portů, který bude 8250.c podporovat - a musíte si dát pozor na to, aby byl pro vaši platformu dostatečně vysoký.
ppc64 po této aktualizaci nefunguje. S tím se počítalo, protože jsem stáhnul benhovy změny v sériových ovladačích. benh má od včerejška patch, který by to měl spravit.

Patch má asi 50K, takže neprojde do LKML. Najdete jej tedy zde:

http://www.arm.linux.org.uk/~rmk/misc/linus-serial.diff

Patch by měli určitě otestovat lidi, kteří používají:

ia64 (ACPI port discovery)
parisc (GSC port discovery)
pnp

Jakmile to bude začleněno, začnu posílat další patche, které budou odstraňovat tabulky sériových zařízení v include/asm-arm/arch-*/serial.h.

Pár lidí nemělo s testy problémy, ale dalším se nedařilo patch aplikovat na současný Linusův BitKeeper strom. Proběhlo ještě pár patchů a v jednu chvíli se Russell zeptal Andrew Mortona: Chtěl bys, aby se tyhle změny nejprve objevily v jednom -mm jádře, předtím než půjdou k Linusovi? Andrew odpověděl: Ani ne - máme spoustu času na zachycení všech chyb.

Diskuze o důvodech pro podporu starých kompilátorů, 76 e-mailů

3. lis - 10. lis

Timothy Miller se zeptal, proč se věnuje tolik úsilí podpoře starších verzí kompilátorů GCC. Jsou-li lidi ochotni upgradovat jádro, nebudou také ochotni upgradovat překladač? Matti Aarnio poznamenal, že nejnovější a nejskvělejší kompilátory nejsou vždy tak skvělé i na jiných architekturách. Giacomo A. Catenazzi podotkl, že kdyby byli lidi přinuceni používat nejnovější kompilátory, přispělo by to k rychlejšímu odhalení chyb v těchto překladačích. Chris Wedgwood oponoval: Problém je, že já chci zkompilovat funkční kernel *teď*, ne čekat, až budou v GCC opraveny chyby, které se tam pro mou architekturu dostaly s verzí 3.2.3. Takže já si zatím ponechám 3.2.2 (za 3.2.2 si klidně dosaďte jakoukoliv verzi). A Miles Bader dodal:

Tohle je dvojnásob pravda na okrajových architekturách.

Např. když pro své CPU používáš kompilátor, který je oproti běžnému gcc pozměněný, výrobce, který změny provedl, dodává nové verze se zpožděním oproti běžnému gcc, a ty změny jsou tak komplexní, že to nechceš opravovat sám.

Máme sice GPL, takže je _možné_ udělat to sám a zprovoznit i nové gcc, ale někdy je fajn mít také možnost nemuset...

Na jiném místě redukoval Christoph Hellwig celý problém na rychlost: Lidi chtějí používat starší překladače proto, že ty nové jsou o hodně pomalejší. Díky tomuto argumentu se rozvinulo nové velké podvlákno. Adam Heath nevěřil vlastním očím a odsekl: To snad nemyslíš vážně, že by tohle byl problém. Ale Martin J. Bligh napsal: Je to pravda. Většinou navíc produkují větší a pomalejší kód. A Chris reagoval: Zkus si to. Řekněme gcc 2.95 vs. gcc 4.0... Když jsem to zkoušel naposledy, byla starší verze více jak dvakrát rychlejší. Adam řekl, že se nepře o tom, jestli tam rozdíl v rychlosti je nebo není, ale o tom, jestli to tolik vadí: Jak často si kompiluješ jádro? To se ukázalo být nevhodným dotazem v konferenci vývojářů jádra. Chris Friesen odpověděl, že mnoho lidí v této konferenci jádro kompiluje několikrát denně. A Valdis Kletnieks napsal, že mnoho vývojářů používá starší hardware, na kterém může kompilace kernelu trvat i několik hodin. Adam několikrát zopakoval, že řešením je prostě koupit lepší hardware, ale to se také nesetkalo s pochopením. Několik lidí se přihlásilo s tím, že od Adama rádi přijmou darovaný hardware.

V jednu chvíli poznamenal Ioan Ionita: Nové verze gcc sice kompilují pomaleji, ale generují rychlejší kód.

Linus Torvalds také reagoval na Adamovo tvrzení, že doba kompilace není důležitá:

Zaprvé, pro mnohé lidi je kompilace jádra to hlavní, co jejich procesor dělá.

Zadruhé, nejde jen o to, že jsou ty kompilátory pomalejší. Nové verze gcc bývají:

pomalejší
generují horší kód
mají více chyb

Dlouhou dobu bylo jediným důvodem pro upgrade gcc podpora C++; základní podpora C šla v nových kompilátorech dolů v každém směru.

Poslední dobou se to trochu zlepšuje, ale do nějaké verze 3.3 nestála řada gcc-3.x kvůli běžnému C za upgrade.

Adam opět zopakoval, že by si lidi měli prostě pořídit lepší hardware, chtějí-li rychleji kompilovat. Linus odpověděl, že ne každý si to může dovolit, a že při výběru počítače nehraje roli pouze rychlost: I já preferuji spíše "pěkný a tichý" před absolutní rychlostí. A připojil: Tvůj argument "používejte nové verze, i když nejsou v ničem lepší" nedává smysl. Nejsou-li lepší, proč je používat? Xose Vazquez Perez odpověděl: Možná proto, že staré nejsou podporované... Adam Linusovi také odpověděl v tom smyslu, že chápe, když lidi používají starší verze, pokud produkují lepší kód. Tvrdil však, že rychlost kompilace sama o sobě není dostatečným důvodem pro použití starého kompilátoru: Pokud se lidi nebudou obtěžovat používat novější překladače kvůli jejich nedostatkům, nebudou ty problémy nikdy vyřešeny. Linus odpověděl:

Jediné, na čem záleží, je "co je nejlepší nástroj". A při vybírání nejlepšího nástroje hraje výkon svou roli. Není to jediný důvod, ale je dost zásadní.

Sám jsi to řekl, když jsi tvrdil, že by si lidi měli prostě koupit rychlejší hardware. Stroj, který používáš, je jedním z dalších nástrojů. Proč kupovat rychlejší stroj, kdyby na výkonu nezáleželo?

Nerozumím tomu, proč nejprve vypustíš výkon a pak ignoruješ i všechny další věci, které jsem popisoval.

A tvůj argument, že "problémy budou opraveny, budeš-li používat novou verzi" ve skutečnosti neplatí. Zaprvé, není-li problém ve staré verzi, vyřeší se to právě tím, že neupgraduješ.

A říct vývojáři "nepoužívám novou verzi proto, že ve srovnání s tou starou stojí za houby", to je úplně v pořádku. A je pravděpodobné, že to bude mít větší motivační účinek, než když uživatelé jako ovce poslušně přecházejí na nejnovější verzi.

Existují lidé, kteří používají Linux-2.0. A jsou asi i lidé, kteří používají dokonce Linux-1.2. A víš co, je to OK. Pro starší stroje to může být ta správná volba - zvláště pokud dělají totéž, co před několika lety. Tvrzení, že se musí upgradovat na nejnovější verzi, to je NESMYSL.

Oprava pro myš na PC100, 9 e-mailů

6. lis - 10. lis

Andries Brouwer si všiml, že nedávná oprava v jádře 2.6.9 odhalila větší problém s ovladačem myši pro PC110. Až do 2.6.9 nefungoval test prováděný tím ovladačem, takže nezískal přístup do paměti, ani nezabral IRQ. Když byl test opravený, myš získala IRQ i RAM, ale kolidovala s ethernetovou kartou, takže nefungovala síť. Myš se pak se svou RAM a IRQ pokusila o I/O, ale vrátily se jí chyba, a proto také nefungovala. Takže oprava v 2.6.9 způsobila, že nefungovalo ani síťování, ani myš.

Rychlou nápravou bylo nastavit při konfiguraci 'CONFIG_MOUSE_PC110PAD=n' a zakázat tak ovladač úplně, ale lepším řešením by bylo detekovat při startu konflikt, a kdyby nějaký problém byl, odmítnout ovladač myši natáhnout. Jenže nevěděl, jak hardware detekovat, takže se v konferenci zeptal, jestli by mu někdo neporadil.

Linus Torvalds navrhl linkovat ovladač do jádra až na poslední chvíli a tím dát ostatním ovladačům šanci zabrat zdroje, což by zabránilo vážnějšímu konfliktu. Ale řekl že nemá tušení, jak testovat přítomnost hardwaru. Zeptal se Alana Coxe, ale ten odpověděl: Mám nějaké informace o registrech. Ten ovladač byl napsán díky rozebrání ovladače pro PC-DOS, který IBM dodávala s PC110. Ten stroj ještě nemá PCI ani DMI, takže neexistuje žádný zřejmý způsob, jak to zjišťovat. Není to něco, bys chtěl vestavěné a ne jako modul na čemkoliv jiném než PC110. Linus odpověděl:

Aha, to je ale věc, kterou testovat můžeme: "má tento stroj PCI?".

Jinými slovy, můžeme mít jednoduchý test "není-li seznam PCI zařízení prázdný, ihned zastav". Nebo ne?

To by znamenalo, že (více méně) každý, kdo by ovladač natáhl omylem, by byl ušetřen starostí.

To se Alanovi líbilo a Linus poslal krátký patch, u kterého byl ve zdrojáku komentář: "Snažíme se vyhnout zapínání tohoto hardwaru, není-li přítomen. Ale nevíme, jak to zjistit. Víme však, že PC110 není PCI systém. Takže pokud nalezneme nějaká PCI zařízení, nejedná se o PC110." Andries i Alan potvrdili, že to na jejich strojích problém vyřešilo.

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