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

Štítky: C, distribuce, FUSE, Git, hardware, IDE, kernel, Linux, patch, PCI, programování, sběrnice, software, souborové systémy, udev, Version Control System

Jaderné noviny 318

30. 8. 2005 | Robert Krátký | Jaderné noviny | 3957×

Boj o odstranění DevFS. Problémy s vyhledáváním IDE hardwaru. Odchytávání chyb s gitem. Nový nástroj pro hlášení oops.

Boj o odstranění DevFS, 36 e-mailů

20. črv - 24. črv

Greg KH poslal patch, který kompletně odstraní DevFS z jádra 2.6. Andrew Morton odpověděl: Moc bojím. Možná bychom to měli nechat chvíli v -mm, ať získáme představu o tom, jak moc nás budou uživatelé nenávidět a kolik jich bude. Greg reagoval: Nějaké stížnosti možná budou. Ale pochybuji, že by pocházely od někoho, kdo používá -mm, protože tihle lidi vědí, jak se věci v jádře mají. Už proběhlo mnoho varování o tom, že se chystá odstranění, a čekal jsem _rok_. Žádná distribuce už nepoužívá pouze DevFS (Gentoo skoro, ale nabízí uživatelům i udev a statický /dev). Andrew na to řekl: A co když to začleníme a během následujících čtyř týdnů nás ta smršť přinutí říct "jejda, to jsme (ještě) neměli dělat"? Arjan van de Ven navrhl na pár týdnů zrušit konfigurační volbu a zjistit, kdo si všimne. Andrew i Greg souhlasili, že to bude dobrý test.

Několik lidí se přimlouvalo za ponechání DevFS kvůli množství práce vyžadované pro přechod na udev nebo jiné řešení. Ale další, mezi nimi i ti, kdo byli dříve proti odstranění, se vyjádřili pro. I pro ně byl přechod dost složitý, ale jak řekl Bill Gatliff Říkám to trochu neochotně, ale vidím, že udev je lepší dlouhodobé řešení. Jakmile bude DevFS pryč, bude pro mě snazší si odůvodnit práci, kterou budu mít s plným přechodem na udev.

Mike Bell se rozohněně dožadoval ponechání DevFS:

Jak je jednou DevFS venku, je pryč nadobro. Není dost dobře možné takovou věc spravovat mimo hlavní jádro. Měli byste vědět, že interní jaderná infrastruktura udev byla vyvíjena téměř výhradně v rámci hlavního jádra. A jak dlouho trvalo, než s tím začalo spolupracovat tolik ovladačů.

Bude docela těžké se DevFS věnovat, když nebudou patche začleňovány, protože jistí lidé už se rozhodli, že DevFS není ten správný způsob. Jako příklad může sloužit rychlá a nekomentovaná smrt patchů umožňujících DevFS nad tmpfs.

Nebo si uvědomte, jak dlouho trvalo, než se udev dostalo do povědomí lidí, jak dlouho už tu bylo. Lidi začali na udev přecházet jen díky léčbě šokem v podobě označení DevFS jako OBSOLETE (zastaralé) už v době, kdy ještě udev nebylo vůbec připraveno DevFS nahradit, takže nebylo ani trochu zastaralé.

Greg Mikeovi připomenul, že DevFS už mělo hlavu na špalku více než rok, a uživatelé se na jeho odchod měli připravovat. Řekl, že pokud lidi neplánovali dopředu, je to z větší části jejich chyba, když teď skončili s plnýma rukama práce.

Mike se bránil a flamewar byl na spadnutí, ale Greg řekl: Věnoval jsem ten čas, který bych strávil odpovídáním v této diskuzi (a dalším lidem, kteří z nějakého důvodu neradi píší do konference, a otravují mě místo toho soukromými emaily typu "nemažte devfs"), a napsal jsem náhradu na 300 řádků, včetně všech potřebných háčků v jádře. Pokud tohle nestačí, odpověz prosím ve vlákně s ndevfs patchem. A bylo ticho.

Problémy s vyhledáváním IDE hardwaru, 15 e-mailů

21. črv - 27. črv

Alan Cox napsal:

Staré ISA/VESA systémy někdy dávají čtvrtý IDE řadič na adresu 0x1e8, 0x168, 0x1e0 nebo 0x160. Linux proto tyhle adresy na x86 systémech prověřuje. Některé PCI systémy však bohužel tyto adresy využívají k jiným účelům, což uživatelům způsobuje zamrzání při bootu na minutu i více, někdy i pád.

Následující patch (už je nějakou dobu ve Fedoře) nechává tyto obstarožní a obskurní ISA porty prověřovat jen na před-PCI strojích. Zdá se, že to takhle všem vyhovuje. A pokud má někdo tak podivný stroj, že by to nefungovalo, parametr ide= by měl pomoci. Nepřekvapuje mě, že se neobjevil nikdo, koho by se to týkalo.

Maciej W. Rozycki poznamenal: U MIPS strojů s PCI sběrnicí ověřujeme ISA IDE porty pouze pokud existuje PCI-ISA nebo PCI-EISA most. To by mohlo být řešení i pro x86 a další platformy, které používají PCI. Alan odpověděl:

Primární/sekundární ISA porty se na PC systémech objevují proto, že zařízení třídy PCI IDE jsou v režimu kompatibility, ne v nativním režimu (takže je možné spouštět staré operační systémy). Také existuje pár starších podivných případů.

Kód PCI vrstvy je dost chytrý na to, aby rozpoznal, kdy PCI i ISA test nalezne stejné zařízení. A umí to dát celé dohromady tak, aby byl tento aspekt v pořádku.

Ověřování třetích a vyšších portů není na PCI strojích bezpečné bez ohledu na přítomnost ISA mostů, takže bych neřekl, že to potřebujeme nějak dále komplikovat - nebo jsem něco nepochopil?

Maciej odpověděl:

Kód se mi líbí, ale přemýšlel jsem o tom, jestli by nebyl možný obecnější přístup.

Odchytávání chyb s gitem, 9 e-mailů

24. črv - 24. črv

Russell King napsal:

Při kompilaci aktuálního git stromu pro ARM vidím:

  CC      arch/arm/mm/consistent.o
arch/arm/mm/consistent.c: In function `dma_free_coherent':
arch/arm/mm/consistent.c:357: error: `mem_map' undeclared (first use in this function)
arch/arm/mm/consistent.c:357: error: (Each undeclared identifier is reported only once
arch/arm/mm/consistent.c:357: error: for each function it appears in.)
make[2]: *** [arch/arm/mm/consistent.o] Error 1

Jak zjistím, co se jinde v jádře změnilo a způsobilo tenhle problém?

S BK šlo u daného souboru požádat o historii revizí pravděpodobných kandidátů a pak vyhledat sadu patchů a prohlédnout související změny.

S gitem...? Nemáme historie revizí pro jednotlivé soubory, takže...

Linus Torvalds odpověděl:

Ohó! Reálný příklad toho, jaké skvělé věci git umí.

No, každopádně je první krok naprosto stejný jako u BK, až na to, že syntaxe je dost odlišná, a git to dělá lépe:

git-whatchanged -p arch/arm/mm/consistent.c

Jenže v tomto případě se v daném souboru nic nezměnilo během celé historie gitu, takže dostaneš prázdnou odpověď. Pojďme do fáze dva, ale nejprve odbočka:

Pokračoval komentářem k Russelově zmínce o historii jednotlivých souborů:

Neukládáme změny jako historie revizí souborů, ale ukládáme je tak, že chceš-li zjistit, co se stalo, je to efektivní i u jednotlivých souborů. Zatímco "anotování" řádek po řádku efektivní není, "co se změnilo" efektivní je.

A git to ve skutečnosti zvládá lépe než BK (nebo jakýkoliv jiný software ukládající historie revizí souborů), protože "git-whatchanged" funguje na adresářích stejně jako na samostatných souborech. A pracuje čistě s cestami, takže můžeš provést "git-whatchanged" na souboru, který byl odstraněn, abys viděl, proč byl odstraněn. U většiny ostatních systémů je těžké zjišťovat, co se stalo něčemu, co už tam není.

Zpět. Problém zjevně nevznikl kvůli změnám v tom souboru, takže historie revizí souboru nepomůže. Ale ničeho se neboj, ještě nejsme v háji. Vzhledem k tomu, že víš, že nešlo o změnu v souboru, a protože víš, co se měnilo v ARM kódu, pojmeš podezření, že na vině bude nějaký obecný linuxový hlavičkový soubor.

Takže fáze 2 je:

git-whatchanged -p include/linux

(což zobrazí všechny změny v include/linux, ale jako patche - proto to "-p"). Spustí se stránkovaný výpis výsledků, takže na to půjdeme jednoduše a provedeme "/mem_map", abychom vyhledali změny zmiňující mem_map. Třeba budeme mít štěstí.

Ani tohle moc nepomůže; ale objeví se podezřívavý prstík ukazující na nedávno začleněné věci kolem sparse-mem od Andy Whitcrofta.

A už máš změnu, na kterou je možné se podívat, konkrétně "sparsemem memory model", commit ID d41dee369bff3b9dcb6328d4d822926c28cc2594.

Když se na to dívám, tak se mi zdá, že to je prostě změna konfigurační volby. A bude to asi ta volba SPARSEMEM, která způsobila chybějící podporu DISCONTIGMEM. Ale už máš někoho, na koho můžeš svalit vinu a žádat ho o pomoc: Andy Whitcroft a Dave Hansen, které jsem dal do CC.

Fázi tři bych začal s:

git-whatchanged -p mm/Kconfig arch/arm/Kconfig

ale v tuhle chvíli už máš asi dostatečnou představu, takže už ti je to jedno.

Nový nástroj pro hlášení oops, 7 e-mailů

24. črv - 26. črv

Michal Piotrowski napsal:

Představuji náš jednoduchý skript, který pomáhá s vytvářením hlášení o chybách:
http://stud.wsi.edu.pl/~piotrowskim/files/ort/beta/ort-b1.tar.bz2 <http://stud.wsi.edu.pl/~piotrowskim/files/ort/ort-a5.tar.bz2>

Proč to děláme?
Protože hodně lidí nemá čas na přípravu dobrých (se všemi důležitými informacemi) hlášení o chybách.

Jak to funguje?
Vytvoří soubor s informacemi o vašem systému (software, hardware, použité moduly atd.), připojí k němu soubor s oopsem a později vše odešle zvolenému správci nebo do konference.

Jak můžete pomoci?
Pokud se vyznáte ve skriptování v BASHi, můžete skript zkontrolovat, přidat užitečné funkce a optimalizovat. Nebo prostě pošlete nápad.

Odezva byla všeobecně kladná a různí lidé nabídli návrhy na vylepšení.

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