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

Štítky: GCC, GNU, hardware, kernel, kompilace, Linux, ovladače, patch, programování

Jaderné noviny 229

18. 9. 2003 | Robert Krátký | Jaderné noviny | 2425×

Patche formátující kód a historie revizí v BitKeeperu. Natažení modulů před bootem. Vydán Linux 2.6.0-test3-mm2. Vývojová strategie pro opuštěné ovladače.

Do konference přišlo celkem 2320 emailů, nejvíce jich poslali Greg KH, Con Kolivas, Jamie Lokier.

Patche formátující kód a historie revizí v BitKeeperu, 27 e-mailů

Dave Jones poslal několik formátovacích změn do jednoho souboru, aby více odpovídal dokumentu CodingStyle.

Larry McVoy měl proti záplatě námitky také proto, že:

Je to jenom formátovací patch. To je nepříjemné pro lidi, kteří BK používají pro debuggování. Když teď dvojkliknu na tyhle změny, ukáže se tvůj formátovací patch, a ne ten patch, který byl poslední významnou změnou.

Jeff odpověděl, že ve vývoji Linuxu jsou CodingStyle patche kulturně přijatelné, pokud vývojář ponechá každý patch malý.

Larry odpověděl: To by mělo být vyváženo přístupem "nezmrv historii revizí, protože ji lidi používají". Jedna věc je přeformátovat nečitelný kód, druhá přeformátovat tento kód, který měl k nečitelnosti daleko.

Eli Carter poznamenal: Možná se nástroj (kontroly revizí) plete do cesty práci a měl by být opraven :). Třeba by pomohla schopnost označit sadu změn jako "formátovací změny" a pak mít možnost ji skrýt nebo udělat nějakým způsobem 'transparentní'. Hmm... "Anotovat pouze změny týkající se vlatnosti X."

Larry napsal, že o tom přemýšlel, ale pak to zavrhl a kromě toho, v BitMoveru máme pravidlo, že "formátovací změny" jsou zakázané a nutíme lidi předělávat své sady změn dokud je nemají správně.

Philip Brown navrhl: Měli byste umožnit změny, které jsou "pouze formátovací" a nemění nijak strukturu kódu. Výsledky můžete prohnat přes stage 1 gcc a pustit je dál pouze pokud bude parsovací strom identický. Larry odpověděl, že BitKeeper se používá na víc než jen na soubory kompilovatelné pomocí gcc.

A Eli se zeptal: Předpokládám, že před commitem mohou proběhnout validátory podle obsahu souborů (CVS to umí)? Validátor by zjistil, že jde pouze o formátovací změnu a nějak by ji jako takovou označil.

Larry napsal, že ano, BitKeeper má takové přepínače, které mohou udělat to, co Eli chce.

Natažení modulů před bootem, 10 e-mailů

Nufarul Alb poslal patch, který umožňuje natáhnout moduly předtím než nabootuje kernel. Christoph Hellwig poukázal na to, že Nufarulův patch je proti 2.4, takže nemá moc šancí být přijat. Navrhl portovat jej na 2.6-test a poslat znovu. Také doporučil psát kód linuxovým stylem spíše než GNU stylem.

Nufarul vysvětlil: To nejsou moje patche. Patří jistému Christianu Koenigovi. Už se o ně nestará a já hledám někoho, kdo by ten projekt spravoval.

H. Peter Anvin doporučil místo toho prostě používat initramfs.

Vydán Linux 2.6.0-test3-mm2, 18 e-mailů

Andrew Morton oznámil 2.6.0-test3-mm2 a prohlásil, že obsahuje "zilióny" oprav, aktualizaci framebufferu a nějaké další vylepšení CPU scheduleru.

Peter Osterlund poslal opravu pro Synaptics touchpady s "multi buttony". Patch pochází od Hartwiga Felgera, který napsal původní patch pro podporu multi buttonů (p00003_synaptics-multi-button.patch). Stejná oprava už je týdny v XFree86 ovladači a zdá se, že funguje dobře (ta část X ovladače je používaná pouze pro kernely 2.4).

Vývojová strategie pro opuštěné ovladače, 12 e-mailů

Během diskuze Russell King řekl, že u starších sériových ovladačů je třeba, aby je někdo převedl na nové jádro sériového ovladače (a opravil rozhraní jádra ovladače, aby s nimi fungovalo).

Sám žádný takový hardware nemá, ale doufá, že se jich někdo ujme a opraví je. Linus odpověděl:

Hele, já s tím úplně souhlasím pro 2.7.x. Ale prozatím už nefungují celý rok, takže se je pokusme opravit tak, aby mohly alespoň pokulhávat s námi.

Já ten hardware taky nemám, ale aspoň by měly být na UP (jednoprocesorových) konfiguracích testovatelné (SMP nefunguje všeobecně pořád, protože ovladače očekávají, že budou mít možnost globálně vyřadit všechna přerušení místo používání správného zamykání).

Zajímalo by mě, jestli ty zatracené věci fungují. Pochopitelně, že už asi není moc lidí, kteří by takový hardware měli. Mohl jsem je prostě přidat do BROKEN seznamu, ale protože by _mohly_ fungovat, zdálo se mi lepší být radši velký optimista ;).

Russell odpověděl: To je pravda. Jenže opačný úhel pohledu je stejně tak platný. Není moc lidí, kteří by ten hardware měli, a ti, kteří ho mají, se nezajímají o vývojové série kernelu, takže i kdybychom je převedli na 2.7, neslyšeli bychom o nich nic do 2.8.

A Linus řekl:

Ano. Ale starosti mi dělá to, že lidi, kteří ten hardware mají, ale ovladač se jim nezkompiluje, si řeknou "no jo, zkusím to znova až vyjde ten _skutečný_ 2.6.0".

Což samozřejmě nebude nic platné.

Takže se snažím zajistit, aby byly všechny nefunkční ovladače dovedeny do funkční podoby. Teď to znamená, že vzhledem k tomu, jak dlouho byly nefunkční, tak se prostě "musí zkompilovat" aby je lidi mohli testovat.

Ten přístup "nechme to nefunkční, aby to někdo jednou mohl udělat pořádně" je v pohodě v ranných fázích vývojové série. Ale teď už bych radši viděl patche, které těm ovladačům umožní čistou kompilaci - i když je lidi nemohou otestovat na skutečném hardware.

Průnik množin lidí, kteří mají hardware, a lidí, kteří mají čas/znalosti na převod ovladače, bude asi prázdný. Zvláště u nezvyklého hardware. Takže pojďme ty ovladače opravit tak, aby se zkompilovaly, i když je nemůžeme testovat, ať je _mohou_ testovat ostatní.

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licenci GPL verze 2.