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

Štítky: CVS, kernel, Linux, ovladače, patch, programování, RAID, software, textové editory, Version Control System, Vim

Jaderné noviny 269

25. 8. 2004 | Robert Krátký | Jaderné noviny | 3460×

Stav začlenění UML do 2.6; patchovací nástroj quilt. Podivné intelovské chování. Linux Trace Toolkit (LTT) v 2.6.

Do konference přišlo celkem 1276 emailů, nejvíce jich poslali Andrew Morton, Jamie Lokier a Jeff Garzik.

Stav začlenění UML do 2.6; patchovací nástroj quilt, 16 e-mailů

26. črv - 3. črc

Paolo Giarrusso se zeptal:

Jaké jsou podmínky pro stabilní zařazení aktualizace UML do 2.6-mm (nebo přímo 2.6.8)? V současné době (když oddělíme malý kousek, který by začleněn být neměl) máme téměř všechno v arch/um a include/asm-um, pak přidání <linux/ghash.h> a dvou filesystémů pro použití pouze s UML a tenhle malý kousek (plus 2 jeho použití v mm/page_alloc.c).

+#ifndef HAVE_ARCH_FREE_PAGE
+static inline void arch_free_page(struct page *page, int order) { }
+#endif

Mohlo by to být přidáno tak, jak to je? Zvláště se to obávám příliš brzy zařadit do 2.6.8, protože když se to naposledy objevilo v -mm, šlo to po jedné verzi zase pryč.

Ten patch lze aplikovat na 2.6.7; současný kód není naopak ani možné zkompilovat, takže není důvod to nepoužít (pokud nechceš odstranit podporu UML / ale protože to jsi nikdy neřekl, potřebujeme ten patch aplikovat). Pokud však některé části toho kódu nechceš, stačí říct; čekám s tím než připravím k poslání ten UML patch.

Andrew Morton odpověděl:

Nebude mi vadit šoupnout to do -mm, pokud to nezpůsobí moc nepříjemností. Naposledy kvůli tomu byly problémy se správou patchů, ale ať už se s tím pralo cokoliv, mezitím to asi bylo začleněno do hlavního stromu, takže to bude OK.

Ale pro začlenění výše by bylo potřeba na tom zapracovat - znovuzavedení ghash.h by nebylo vítané (myslel jsem, že se toho Jeff zbaví). A posledně byly součástí patche i nějaké ovladače blokových zařízení, které prováděly zastaralé věci jako ve 2.4.

Obecně se zdá, že UML v 2.6 je dost pozadu a jednou ten patch budeme muset rozdělit, prohlédnout a opravit.

Jeff Dike odpověděl:

Jo. Už mi došlo, že jsem si to pěkně s BK a mým současným stylem práce zavařil. Uvažuji o používání quilt. Vzal bych všechny změny od chvíle, kdy Linus naposledy začlenil UML (2.5.69 nebo tak nějak) a rozdělil je na rozumné patche.

Bude to dost práce, ale myslím, že je potřeba ji udělat.

Diskuze se v tuto chvíli stočila k nástroji quilt. Paul Jackson napsal:

Dobrá věc.

Trošku jako nabitá zbraň bez pojistky. Naučíte se pár nových způsobů, jak se střelit do vlastní nohy, a začnete být dobří v první pomoci. S takovou servisní prací vám pomůže uložená osobní historie revizí patchů. CVS, RCS, lokální bitkeeper nebo (pro přestárlé hackery jako jsem já) samotné SCCS nebo něco podobného. Quilt se postará o patche, ale sám o sobě historii nezachová.

Veškerý software je rozdělen na dvě části - pevný a pohyblivý.

Jakmile je něco přijato do hlavního kernelu, je to pevné. Už nelze jít zpět - lze nad tím pouze vrstvit opravy. Bitkeeper je pro tohle ideální.

Ale nedokončená práce, pro kterou jste hlavním zdroje vy sami, je pohyblivá. Můžete jí rozdělovat, přehazovat a předělávat, což je přesně to, co chcete pro získání nejlepší sady patchů. A na to je nejlepší quilt a podobní.

Závěr - používejte quilt (s oblíbeným systémem kontroly verzí) nad Bitkeeperem.

Otázka - jaké existují nástroje pro pohodlné odesílání sad patchů? Sestavování mnoha souvisejích sad emailů v GUI mailovém klientu je trochu zdlouhavé a náchylné k chybám. Je to zjevný kandidát pro skriptování.

Podivné intelovské chování, 18 e-mailů

28. črv - 1. črc

Roland McGrath napsal:

Andrew Cagney na tento problém narazil při práci na GDB. Predpokládám, že ta chyba tam byla vždycky, ale testoval jsem to jen na 2.6 jádrech.

Když dokrokujete do trap instrukce, nedostanete SIGTRAP dokud neproběhne také instrukce následující po té trap instrukci. Demonstroval jsem to na třech případech: `into' generuje SIGSEGV, který je potlačen přes ptrace; zadání systémového volání `int $0x80'; a zadání systémového volání `sysenter' přes vstupní bod vsyscall.

Na https:// bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126699 najdete funkční testovací program a kompletní podrobnosti o reprodukování problému s pomocí gdb.

Linus Torvalds odpověděl:

To je dokumentované intelovské chování. Jestli si dobře pamatuji, tak zároveň garantuje, že v některých podivných případech nebude postup zastaven.

A já odmítám zpomalení rychlé cesty [fast path] jen kvůli tomu. Nejenže takhle Linux vždycky fungoval, ale pokud vím, tak všechny ostatní x86 operační systémy dělají to samé.

Linux Trace Toolkit (LTT) v 2.6, 11 e-mailů

30. črv - 6. črc

Peter Martuccelli poslal patch pro subsystém 'audit', Andrew jej přijal a vedlo to k následující diskuzi. Karim Yaghmour napsal:

Společně s dalšími lidmi se snažím procpat do jádra Linux Trace Toolkit posledních 5 let. A přitom ten kód je téměř shodný s tím, který přidává ten audit patch. Zatím jsme však vždy dostali odpověď ve smyslu "je to přeplácané" a Linus nám řekl, že pro podobnou věc nevidí žádné použití.

To jsme prostě jen neodhalili tajný způsob potřesení rukou?

Skutečně bych rád dostal nějakou radu, protože jsem přesvědčen, že jsme zkusili každý trik z návodu: posílání patchů ke kontrole, zajímání se o názor vývojářů jádra, portování na více architektur, modularizace systému, atd.

Andrew odpověděl, že kód auditu je daleko méně intrusivní než LTT. Připojil seznam souborů modifikovaných oběma projekty ukazující daleko větší počet u LTT a řekl, že LTT všude přidává háčky.. A pokračoval:

Bezpečnostní kód má také háčky všude, ale poskutuje funkčnost pro koncového uživatele, místo aby to byl čistě vývojářský nástroj.

Podpůrné nástroje pro vývojáře jsou fajn, ale nejsou tak přesvědčivé jako funkce pro koncové uživatele. Protože obecenstvo je menší a vývojáři vědí, jak aplikovat patche a překompilovávat.

Ohledně 'tajného potřesení rukou' Andrew řekl: Jde o rovnováhu mezi (průběžnou náročností na správu vynásobenou počtem ovlivněných vývojářů) versus (přidaná funkčnost vynásobená počtem uživatelů, kteří z ní budou mít prospěch). Podle mě LTT (a kgdb a různé další podpůrné věci pro vývojáře) nenabízejí dobrý poměr. Navrhl, aby LTT používalo háčky kprobe.

Karim odpověděl na mnoha úrovních. Ze všeho nejdříve argumentoval, že patch není tak velký, jak si Andrew myslí, a že podívá-li se někdo na to, co skutečně dělá, zjistí, že většina háčků jsou jednoduché jednořádkové úpravy. Ale nejrozsáhleji se Karim vyjádřil k tomu, že Andrew nazval LTT vývojářským nástrojem. Upozornil, že pro debugování kernelu je naopak funkčnost LTT naprosto nedostatečná a LTT tedy vůbec není zamýšleno jako nástroj pro vývojáře jádra. Je to však platný nástroj například pro sysadminy nebo vývojáře aplikací, kteří mohou jeho výstup využít k analýze problémů, se kterými se na svých systémech potýkají.

Andrew řekl, že Karim jeho slova špatně pochopil - Andrew měl na mysli všechny vývojáře, ne pouze vývojáře jádra. Andrew objasnil, že chtěl říci, že LTT je nástroj pro vývojáře jakéhokoliv druhu, ne pouze těch od kernelu. Díky tomu Andrew vyvodil, že by množství uživatelů bylo omezeno, a že takoví uživatelé by měli být schopni si patche aplikovat dle svého uvážení sami.

Karim odpověděl: Mohou-li se do jádra dostat funkce jako UML, oprofile, audit, bezpečnostní háčky, vserver, atd., které jsou určeny pro stejnou skupinu uživatelů jako LTT, těžko hledám opodstatnění pro odmítání LTT pouze na základě toho, že z něj nemohou těžit ti nejméně počítačově vzdělaní uživatelé Linuxu. Ale diskuze nijak nepokračovala.

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