Jaderné noviny 193

2. 12. 2002 | Leoš Literák | Jaderné noviny | 2711×

Pročišťování aplikačního rozhraní devfs. Stav ACPI. Problémy s moduly v řadě 2.5. Bugzilla sleduje chyby v jádře.

Poděkování

Toto číslo věnuji Richardu Bukovanskému, který byl tak laskav a vytvořil mi XSL transformaci pro převod přeloženého kernel trafficu do HTML. Tím mi ušetřil spoustu nudné opakující se práce. Děkuji!

Do konference přišlo celkem 2246, nejvíce napsali Alan Cox, Jeff Garzik, Rusty Russell.

Pročišťování aplikačního rozhraní devfs, 15 e-mailů

Alexander Viro se rozhodl podrobit devfs dalšímu hloubkovému průzkumu. Poslal svá zjištění, z nichž vyplynulo, že

1. spousta funkcí exportovaných z devfs není vůbec používána. Nikde.
2. podstatná část ostatních funkcí je používána pouze projektem hwgraph od SGI.
3. mnohé funkce obsahují zbytečné argumenty.
4. devfs nepoužívá strukturu dev_t, ale přenáší major a minor čísla zvlášť, což vede ke zbytečně komplikovanému kódu jak u devfs tak u volajícího kódu.
5. devfs_entry je noční můra, je to struktura, která obsahuje union, jehož položkou je struktura obsahující funkce, příznaky a union z dev_t (pár major a minor číslo) a size_t. Důvodem je snaha o používání jedné položky pro obyčejné soubory, znaková i bloková zařízení. Jejich jediným společným bodem je sada příznaků.

Richard Gooch odpověděl, že odpoví na Alexandrovy body, až najde čas za týden či dva. Dodal, že se bojí porušení kompatibility mezi ovladači řad 2.4 a 2.5. Alexander odpověděl:

Na to už je trochu pozdě. Kompatibilita mezi 2.4 a 2.5 byla u ovladačů již narušena a devfs se neobjeví poblíž vrcholu seznamu.

Jinde se Ryan Anderson zeptal Alexandra, zda by po vyčištění, které navrhnul, byl sám ochoten používat devfs. Alexander odpověděl, že nikoliv. Theodore Y. Ts'o navrhnul úplně odstranit devfs a poznamenal, že jej stejně nepoužívá moc lidí. Okamžitě se však ozvala řádka lidí, kteří jej používají a mají rádi.

Stav ACPI, 7 e-mailů

Andrew Grover ohlásil další verzi ovladačů ACPI, která je dostupná na adrese sf.net/projects/acpi. Tato verze řeší problémy se čtením informací z baterie a zrychluje jejich načítání.

Problémy s moduly v řadě 2.5, 20 e-mailů

Christoph Hellwig si postěžoval Linusi Torvaldsovi a Rusty Russellovi:

Co se to sakra děje s moduly v 2.5-CURRENT?

Rustyho superpatch všechno rozboural (vzpomeňte si, že jsme v zamrznutí kódu). Místo aby dělal jednu věc, tak provádí tři zcela různé věci najednou! Měli jsme použitelné jádro 2.5 a přesně teď během zamrznutí nových vlastností, kdy čekáme na testéry, vše rozbijeme?

Linus odpověděl:

Zcela otevřeně, v tuto chvíli by záložní řešení znamenalo, že vůbec nic nebude začleněno. Přišlo to ještě před zmražením kernelu, ale rozhodl jsem se začlenit tento patch později kvůli své zaneprázdněnosti. A myslím si, že je hoden začlenění (je zde ještě několik patchů, o kterých uvažuji, například kprobes a posixový časovač, možná kexec).

Lidé, pro které je současná situace kolem modulů obtížná, mohou prostě do jádra zakompilovat součásti, které potřebují.

Na to reagoval Alan Cox:

To prakticky znemožní ladění ovladačů. Dále bude nemožné zkompilovat jeden kernel pro řadu různých strojů. Navíc PCMCIA pracuje jen jako modul a nyní nefunguje kvůli rozbitému mazání modulů [unload]. Na druhou stranu přepis modulů má několik hezkých vlastností a kombinované modutils vyřeší elegantně některé problémy. Nejvíce je třeba dokumentace, aby lidé mohli opravit ovladače pro tuto změnu.

Linus souhlasil, že PCMCIA je vážný problém, na který zapomněl. Ale dodal, že myslel, že Alexander Viro přesvědčil Rustyho udržovat kompatibilitu. Jenže Rusty napsal:

Ty jsi přesvědčil mne, abych neporušoval zdrojový kód žádného modulu: kdykoliv jsi odmítnul mé záplaty, sestavil jsem další makro pro kompatibilitu .

Bugzilla sleduje chyby v jádře, 93 e-mailů

Martin J. Bligh ohlásil, že spustil bugzillu na sledování chyb v jádře. Najdete ji na adrese http://bugme.osdl.org. Poprosil vývojáře, aby se zaregistrovali a vkládali zde nalezené chyby. Bugzilla je zatím určena jen pro řadu 2.5 a jejím hlavním účelem je urychlit vytvoření řady 2.6. Je třeba ještě vytvořit lepší dělení na kategorie, což se časem stane, jak bude narůstat databáze chyb.

Pete Zaitcev se přihlásil jako správce chyb pro platformu Sparc a zeptal se, kdo je administrátor bugzilly. Ozval se Khoa Huynh, který věnuje část svého času pro správu bugzilly. Jeho tým z IBM sídlí v různých oblastech a časových zónách, od Texasu po Indii. Tým poslední dva roky pracoval na odstraňování linuxových chyb pro interní účely a nyní by chtěli pomoci udržovat tuto databázi ve svém volném čase. Nicméně dobrovolníci z komunity jsou vítáni, zvláště až naroste objem ukládaných chyb.

Jednotliví vývojáři se začali hlasit o odpovědnost. Paul Larson se zeptal, zda stačí registrovat chybu v bugzille nebo je nutné zaslat informaci i do konference. Robert Love odpověděl, že rozhodně je důležité stále oznamovat je v konferenci. Pete Zaitcev však podotkl, že je možné přidat konferenci jako CC během registrace chyby. David S. Miller napsal, že odmítá pracovat na chybách, které nejsou v Linusově stromu. Hned první přiřazená chyba se totiž týkala jen patchů od Andrewa Mortona. Eric Northup navrhnul vytvořit kategorie pro ostatní stromy, s čímž Alan Cox souhlasil. Poprosil o vytvoření produktu 2.5-ac a přiřazení všech jeho chyb.

Larry McVoy napsal, že BitKeeper používá unikátní jména pro každý changeset a nyní upravují BK/Web tak, aby používal tato unikátní jména místo revizí. Takto bude možné spojit oznámení chyby přímo s changesetem v Linusově stromu. Khoa byl nadšen z této vlastnosti a zeptal se na její formát. Larry odpověděl, že momentálně používají něco jako

torvalds@home.transmeta.com|ChangeSet|20021115061315|00914

což je hnusné. Plánují to změnit na kontrolní součet typu dSD4okOiGmLGDcqOTpQPFQ==. Pak bude stačit jen otevřít následující URL:

http://linux.bkbits.net:8080/linux-2.5/cset@dSD4okOiGmLGDcqOTpQPFQ==

a získáte vždy stejná data.

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

       

Komentáře