Kernel Traffic #269 For 19 Jul 2004

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.

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 to 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.

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.

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 j sem 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í.

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.

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

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é.

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.

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.