Portál AbcLinuxu, 5. května 2025 15:11
Aktuální verze jádra: 2.6.26. Linusovy úvahy uprostřed začleňovacího okna. Citáty týdne: Jevgenij Poljakov, Peter Zijlstra, Jesse Barnes, Al Viro. Další citáty týdne. Začleňovací okno 2.6.27, část druhá. Linux-next se setkává se začleňovacím oknem. Sledování: možností je dost: SystemTap; Ftrace; Sledovací body; Sledovací háček.
Začleňovací okno 2.6.27 zůstává otevřené, takže v době psaní tohoto článku není žádné vývojové vydání jádra. Do repozitáře hlavní řady stále proudí patche; nejvýraznější záležitosti jsou shrnuty níže.
Stabilní aktualizace 2.6.25.12 je v době psaní tohoto článku revidována; měla by být vydána okolo 24. července. Navržená aktualizace obsahuje 47 patchů, které implementují širokou škálu oprav.
Linus poslal oznámení, že začleňovací okno 2.6.27 je z poloviny hotové a že si na pár dní dá pauzu. V několika posledních dnech jsem začlenil 50+ stromů a i když o některých se vedla poněkud 'ostřejší diskuze' (víte, o koho se jedná ;), doufám, že ve skutečnosti jsme v rozumně dobrém stavu, i když je polovina začleňovacího okna, a že lidé budou testovat snapshoty jádra, i když nejsem připraven vydat -rc1
Distribuované ukládání, které jste dříve znali, již není. Místo toho je zde vyvíjen zcela nový projekt, jehož hlavním cílem je poskytnout transportní vrstvu pouze pro blokové požadavky. Považujte ho za síťové blokové zařízení [network block device] nadopované steroidy. Považujte ho za iSCSI nadopované steroidy. Považujte ho za ATA přes ethernet [ATA-over-Ethernet] ještě více nadopované steroidy. A to je jenom příklad toho, co by všechny tyto protokoly mohly získat. A jenom to.
-- Jevgenij Poljakov nedostal zprávu o "nulové toleranci dopingu"
Jestli chcete, aby lidé od jádra podporovali váš projekt, budete je muset potěšit. Tak je to prosté. Pokud to znamená radikálně váš projekt restrukturalizovat a/nebo rozbít zpětnou kompatibilitu, budiž. Taková je cena za to, že nespolupracujete od začátku.
Jestliže tvrdohlavě odmítáte spolupracovat, tak ten projekt buď opustíte, nebo přilákáte fork/přepsání, pokud se někomu jinému zdá, že váš nápad za tu práci stojí.
-- Peter Zijlstra (o SystemTap)
Být dobrým občanem v zemi Linuxu často znamená vylepšovat celé subsystémy místo cpát hromadu úžasných vlastností do jednotlivých ovladačů. Pracovat tímto způsobem může být těžší, ale zisk se šíří a vylepšuje Linux jako celek.
-- Jesse Barnes
Co se toho týče, raději bych viděl, kdyby se o implikacích přemýšlelo a byly zmíněny v changelogu. Na druhou stranu to, co je zmíněno výše, ukazuje na příklad ze života, kde se u rozbití nepřišlo na to, že má vliv na bezpečnost. Zjevně chybné chování (například leak) je zpozorováno a opraveno. Oprava zjevně vypadá dobře, chyba, kterou řeší, je zjevně skutečná a má cenu ji opravit, takže jde do stromu... Jinými slovy nelze spoléhat na to, že patche, které uzavírají bezpečnostní díry, tak budou označené. Toho by si nejprve museli všimnout jejich autoři.
-- Al Viro (přečtěte si to celé)
Pročišťování kódu občas odhalí zásadní neshody o tom, jak má kód vypadat; zde někteří ostřílení hackeři jádra ukazují, jak je to správně.
Rusty si svým podrážděným způsobem stěžoval, že makra definující konstanty by měla mít jména, která nějak přesně odráží účel těch konstant.
Krom toho, že PTE_MASK neposkytuje nejmenší nápovědu ohledně toho, co je vlastně maskováno, a je matoucím způsobem podobná názvům funkčně úplně jiných PMD_MASK, PUD_MASK a PGD_MASK, nevidím, v čem je problém.
Slyšel už Rusty o ekonomii zdravého toku přicházejících regresí? Co si počneme bez matoucích jmen a chyb, které se těžko hledají? Nejdřív napíše jednoduchý a čitelný hypervisor (a zničí tím celý průmysl založený na nesrozumitelnosti!) a teď tohle. To je tak neamerické a neaustralské. Mám strach.
-- Ingo Molnár
Jsem znechucen tímto nevhodným důrazem na průhlednost místo na nesrozumitelnost. Každému by zde mělo být jasné, že obojí mít nemůžeme! Naštěstí je zde způsob, jak můžeme situaci částečně napravit. Ingo, začleň prosím
[...]
+/* Na tomto řádku je něco podezřelého: vizte komentář u PTE_PFN_MASK. */ #define __PHYSICAL_MASK ((phys_addr_t)(1ULL << __PHYSICAL_MASK_SHIFT) - 1) @@ -19,6 +20,7 @@ /* PTE_PFN_MASK extrahuje PFN z (pte|pmd|pud|pgd)val_t */ +/* Tento řádek je vcelku delikátní. Vizte komentář u __PHYSICAL_MASK výše. */ #define PTE_PFN_MASK ((pteval_t)PHYSICAL_PAGE_MASK)
V době psaní tohoto článku bylo od vydání 2.6.26 do gitového repozitáře hlavní řady začleněno přes 6200 sad změn. Zdá se, že začleňovací aktivita se poněkud zpomaluje; vypadá to, že většina hlavních stromů byla přetažena. Andrew Morton ale ještě nezačal do hlavní řady stěhovat -mm strom; dokud se tak nestane, lze očekávat, že začleňovací okno zůstane otevřené.
Změny viditelné pro uživatele začleněné od shrnutí z minulého týdne zahrnují:
Jsou zde nové ovladače pro
Také je zde nový PCI "ovladač pro detekci slotů", který se pokusí najít všechny PCI sloty v systému a vytvořit odpovídající záznamy v /sys/bus/pci/slots.
Povšimnutíhodné: sada ovladačů pro video "gspca", která byla dlouho udržována mimo strom hlavní řady, byla začleněna. Tyto ovladače podporují velké množství video zařízení; díky jejich začlenění je většina kamer na trhu v Linuxu podporována.
Ovladač pro laptopy Fujistsu byl aktualizován, nyní má lepší podporu pro horké klávesy a podsvícení u více modelů.
Byl začleněn souborový systém UBIFS pro úložná zařízení založená na flash.
Byly začleněny patche pro vícefrontové síťování
Architektura IA-64 získala implementaci paravirt_ops pro podporu virtualizace.
Nové adresáře v /sys/dev/char a /sys/dev/block obsahují ukazatele na záznamy v sysfs pro zařízení seřazené podle čísla zařízení.
Změny viditelné pro vývojáře jádra zahrnují:
Byla začleněna nová infrastruktura pro uspávání do RAM a na disk, která obsahuje širší sadu callbacků pro události spojené se správou napájení. Rozhraní pro PCI a platformové sběrnice byly rozšířeny o podporu této nové infrastruktury.
TTY vrstva pokračuje ve vývoji; významné změny zahrnují zavedení nové struktury tty_port, která má držet informace společné pro všechny TTY porty, a přepracování kódu pro správu linky.
Kód mac80211 má nyní nový modul, který může simulovat libovolný počet IEEE 802.11 rádií; je vhodný pro testování funkce mac80211 a přidružených nástrojů v uživatelském prostoru.
Je k dispozici nový mechanismus "rfkill" pro sjednocené ovládání přepínačů "vypnout rádio" na bezdrátových zařízeních.
Mnoho s formátem spojených callbacků [zpětných volání] ve Video4Linux2 bylo přejmenováno tak, aby odpovídaly jménům s nimi spojených typů bufferů. Callback vidioc_enum_fmt_vbi_cap() byl navíc označen jako zastaralý a k odstranění v 2.6.28.
Vrstva videobuf má nyní podporu pro řadiče, které neumí rozsyp/sesbírej [scatter/gather] I/O.
Framework pro USB "věcičky" byl výrazně přepracován, aby poskytl lepší podporu pro kompozitní zařízení.
Prototyp pro device_create() se změnil:
struct device *device_create(struct class *class,
struct device *parent,
dev_t devt,
void *drvdata,
const char *fmt, ...);
Ti, kteří vidí podobnost s device_create_drvdata(), mají pravdu; všichni uživatelé ve stromě byli konvertováni na toto rozhraní, staré device_create() bylo odstraněno a device_create_drvdata() bylo přejmenováno. V této chvíli makro volá device_create_drvdata(), aby věci dobře fungovaly, ale toto makro pravděpodobně před konečným vydáním 2.6.27 zmizí.
UIO ovladače v uživatelském prostoru mohou nyní do zařízení /dev/uioX zapsat znaménkovou hodnotu, která povoluje a zakazuje přerušení.
Debugfs má (konečně) funkci pro odstranění celého stromu adresářů:
void debugfs_remove_recursive(struct dentry *dentry);
Výsledkem je, že kód, který vytváří hierarchie v debugfs, si již nemusí pamatovat dentry každého souboru, který vytvoří.
Závěr začleňovacího okna 2.6.27 bude popsán příští týden.
Nedávné články v Jaderných novinách o stromě linux-next poznamenávaly, že i když tento strom fungoval ve své roli identifikovat konflikty při začleňování mezi subsystémovými stromy dobře, ještě neprošel celým vývojovým cyklem jádra. 2.6.27 bude první vydání, ve kterém linux-next existoval v celém předchozím cyklu; teoreticky všechno, co jde do 2.6.27, by mělo nejprve vyzrát v linux-next. Jak se blíží konec začleňovacího okna 2.6.27, měli bychom se podívat, jak byl linux-next tímto procesem ovlivněn.
Jeden by si mohl myslet, že správce linux-next Stephen Rothwell by měl mít možnost dát si během začleňovacího okna pauzu; že by to teď měla být v podstatě záležitost sledování toho, jak se linux-next přelévá do hlavní řady. Jak se tak stává, denní zpráva linux-next (příklad) naznačuje slušné množství tahanic o to, že je potřeba vyřešit konflikty při začleňování, chyb při překladu a dalších. Je pro to mnoho důvodů, jedním z nich je to, že subsystémové stromy jsou do hlavní řady začleňovány v pořadí, které nemá k jejich v pořadí v linux-next žádný vztah. Patche, které zůstávají v linux-next, jsou aplikovány do velmi nestabilní základny.
Dalším zajímavým fenoménem je nemalé množství patchů, které se v linux-next objevují během začleňovacího okna. Některé z nich jsou ve skutečnosti patche zamýšlené pro 2.6.28; jakmile správci vyhodili své patche pro 2.6.27 do hlavní řady, začínají sbírat věci pro další v pořadí. Stephen je požádal, aby to nedělali - aby nebyl do linux-next směrován materiál pro 2.6.28 až do doby, než bude vydáno 2.6.27-rc1. Cílem je, aby byl linux-next v době, kdy vyjde 2.6.27-rc1, téměř prázdný.
Další patche jsou zase míněny do 2.6.27, ale svůj čas ve stromě linux-next nestrávily. To občas vedlo k nevrlosti vývojářů. Je ale zajímavé uvést, že jeden z největších případů vyhýbání se linux-next - začlenění vícefrontového síťového kódu Davida Millera, který ho dokončil před několika hodinami - způsobil relativně málo stížností. Různé jiné typy konfliktů ale způsobily stálý proud jadrných poznámek od Andrewa Mortona (který má tu nešťastnou pozici, že svou práci zakládá na linux-next) o tom, jak nové věci měly být v linux-next už týdny.
Dalším tématem řekněme barvité konverzace byl TTY subsystém, který nyní Alan Cox podrobuje tolik potřebnému proklestění. Někteří vývojáři nebyli spokojeni s tím, že Alan začlenil kód, který se nedal přeložit, i když byl problém v linux-next již identifikován. Alan byl místo toho podrážděný, že ho jiní vývojáři zaskočili vlastními změnami v TTY vrstvě, kvůli kterým se Alanovy patche nezačlenily. Alan má podivné názory na testování svých patchů, takže rozřešení tohoto typu konfliktu vyžaduje provést novou sadu testů regresí a podobného; poté, co se to stalo několikrát zas sebou, začal být poněkud prchlivý. Zdá se, že tyto záležitosti jsou již vyřešené, ale myšlenkou linux-next bylo zabránit tomu, aby se vůbec staly.
Dalším zdrojem občasných problémů se začleňováním je změna základního bodu [rebase] stromů. Změna základního bodu je v řeči gitu proces modifikace historie commitů v repozitáři tak, že série patchů vypadá, jako by byla napsána proti pozdější verzi kódu, než proti které byla napsána skutečně. To může být užitečná technika; vygeneruje sérii patchů, která se čistě začlení do současného stavu stromu bez nutnosti vytvářet nehezké slučovací commity.
Změna základního bodu může být v kontextu linux-next velmi užitečná. Jestliže testování objeví patch, který znemožní překlad, jednoduché začlenění opravy zanechá v historii období, ve kterém jádro nelze přeložit, a to je špatné pro lidi, kteří dělí půlením [bisection]. Použitím schopností gitu měnit historii lze patch, který za to může, opravit na místě a všechny důkazy o chybě zmizí. Zjednodušeně lze ten trapný commit, který zmiňuje Eurasijské tažení, opravit tak, aby správně oznamoval, že s Východní Asií jsme byli ve válce vždycky.
Změna základního bodu repozitáře ale (z principu) mění historii, během tohoto procesu se vytvoří zcela nová sada commitů. Tyto commity jsou nový kód v tom ohledu, že jakékoliv výsledky testování starších verzí již nemusí platit. Tyto commity také mají nová jména, takže každý další vývojář, který používal starší verzi repozitáře, je setřesen a neschopen začlenit. Záležitosti spojené se změnami základního bodu se během začleňovacího okna objevily několikrát, což Linuse vedlo k zaslání série přednášek o problémech, které může změna základního bodu přinést. Měnění základního bodu je zjevně nástroj, který musí být používán omezeně, ale občasná taková změna může v kontextu linux-next nakonec vést k lepšímu slučování. Nalézt tu správnou rovnováhu je něco, co se bude muset každý vývojář naučit.
Začleňovací okno je poněkud neklidný čas. Proces svádění práce několika set vývojářů do hlavní řady v období dvou týdnů pravděpodobně nikdy nebude příjemná zkušenost. Ale přes několik zádrhelů bylo (zatím!) začleňovací okno 2.6.27 jednodušší než 2.6.26. Přítomnost linux-next s tím téměř určitě má nějakou souvislost. Role tohoto stromu se dál vyvíjí, ale výhody lze již pocítit.
Před třemi týdny LWN věnovalo pohled obnovenému zájmu o dynamické sledování s důrazem na SystemTap. Sledování [tracing] je trvalka na seznamu přání koncových uživatelů; pro společnosti, jako je Sun Microsystems, je to užitečný nástroj, kterým si přejí ukázat, že jejich nabídka (například Solaris) je Linuxu nadřazená. Není překvapující, že je velký zájem implementovat sledování v Linuxu; překvapující však je, že po celém tom čase Linux stále nemá na DTrace odpověď nejvyšší kvality - i když by se dalo dohadovat, že Linux měl fungující sledovací mechanismus dlouho předtím, než se DTrace objevil.
I běžný čtenář jaderné mailové konference by si všiml, že v současnosti kolem poletují patche týkající se sledování. Je jich ve skutečnosti tak moc, že je těžké sledovat je všechny. Tento článek se v rychlosti podívá na kód, který byl zaslán, ve snaze objasnit různé možnosti.
SystemTap zůstává pravděpodobným sledovacím řešením pro Linux. Brání mu ale několik problémů, včetně záležitostí ohledně použitelnosti, kompletního nedostatku statických sledovacích bodů v hlavní řadě jádra a nulové schopnosti sledování z uživatelského prostoru. Několik jaderných vývojářů se snaží SystemTap zprovoznit a hlásí problémy, které mají. Pokud vezmeme za pracovní hypotézu to, že jestliže nejsou schopni SystemTap rozchodit ani jaderní hackeři, mnoho dalších uživatelů pravděpodobně také narazí na těžkosti, pak bychom mohli udělat závěr, že reagovat na ohlášené problémy bude pro vývojáře SystemTapu prioritou.
Zdá se, že vývojáři SystemTapu se o tato hlášení zajímají, což je dobré znamení. V oblasti SystemTapu se dějí další věci, včetně vydání verze 0.7 15. července. Toto vydání přidává mnoho nových vlastností a sad sledovacích míst [tapset] a také mnoho příkladů. Mezitím Anup Shan zaslal zajímavé sjednocení SystemTapu a frameworku pro vkládání chyb, který sadě sledovacích míst umožní ovládat vkládání chyb a sledovat výsledky.
James Bottomley si s kódem SystemTapu trochu hrál; jedním výsledkem této práce jsou změny kódu SystemTapu pro interní přemisťování [internal relocation] ve snaze zajistit, aby byl akceptovatelnější pro začlenění do hlavní řady. Nelze pochybovat o tom, že mimostromová povaha velké části podpůrného kódu SystemTapu ztížila postup tohoto kódu, takže je vítáno jakékoliv vylepšení, které zvýší pravděpodobnost, že bude kód začleněn.
Od Jamese je také tento patch, implementující nový způsob, jak do jádra vložit značky. Přidání značek (nebo statických sledovacích bodů) bylo vždy problematické kvůli tomu, že mnoho z těchto značek z podstaty potřebuje jít do některých s nejžhavějších kódových cest v jádře. Aby podporovaly dynamické sledování, musí být tyto značky dostupné na produkčních systémech, takže musí fungovat, aniž by vytvořily nějaké významné regrese výkonnosti. Kódu statických značek, který je v jádře (ale většinou se nepoužívá) bylo věnováno dost práce, ale některým vývojářům se příliš nechce je vkládat do cest kritických pro výkonnost.
Jamesův patch na tyto obavy reaguje odstraněním sledovacích bodů zcela mimo kódovou cestu. Místo přidávání nějaké značky do kódu tyto značky pouze do jádra vloží poznámku, kde má značka být; poznámka je uložena v oddělené části jádra. Tato informace je v době běhu dostačující k tomu, aby bylo možné vložit skutečný skok do sledovací funkce, pokud chce někdo vidět data z tohoto sledovacího vodu. Dodatečná výhoda je v tom, že tyto značky nezasahují do žádných optimalizací, které dělá překladač. Ostatní řešení mohou vložit optimalizační bariéry, které sice zjednodušší život sledovacímu subsystému, ale také mají vliv na rychlost kódu, i když není sledování aktivní.
Text výše uvádí, že kód jaderných statických sledovacích bodů se "téměř nepoužívá". To by se dalo lépe říci jako "vůbec", až na to, že jádro 2.6.27 bude obsahovat uživatele v podobě frameworku ftrace. Jedna věc, díky které je ftrace opravdu unikátní, je, že dokumentace nejenom že byla začleněna před samotným kódem, ale hodně dlouho před ním: jádro 2.6.26 obsahuje skvěle napsaný soubor Documentation/ftrace.txt.
Framework ftrace (což je zkratka pro "sledovač funkcí" [function tracer]) je jedním z mnoha zlepšení, která pocházejí ze snahy o realtime jádro. Na rozdíl od SystemTapu se nesnaží být komplexní a skriptovatelný nástroj; ftrace je mnohem více orientován na jednoduchost. Je zde sada virtuálních souborů v adresáři debugfs, které mohou být použity k povolení jednotlivých sledovačů a prohlížení výsledků. Sledovač funkcí, po kterém je ftrace pojmenován, jednoduše vypíše každou funkci, která se v jádře zavolá, ve chvíli, kdy se to stane. Jiné sledovače se dívají na latenci probouzení, události, které povolují a zakazují přerušení a preempci, přepínání úloh atd. Jak by se dalo očekávat, dostupné informace se nejvíce hodí vývojářům, kteří v Linuxu pracují na vylepšení reakční doby v reálném čase. Ftrace framework ale umožňuje jednoduše přidávat nové sledovače, takže jsou velké šance, že budou přidány další typy událostí, až vývojáři vymyslí věci, na které by se chtěli podívat.
Mechanismus jaderných značek má být způsob, jak do jádra vkládat sledovací body. Za tímto účelem bylo věnováno hodně úsilí tomu, aby byly tyto značky rychlé; ze zcela praktických důvodů jsou to sady instrukcí no-op, dokud je někdo nechce zapnout; v tu chvíli se do běžícího jádra vloží sledovací kód. Od té doby, co byly začleněny, byly značky v jádře předmětem několika stížností.
Jaderné značky především používají poněkud podivný mechanismus, kterým zajišťují, že jsou všechny argumenty předané sledovací funkci správně interpretovány. S každou značkou je spojený formátovací řetězec ve stylu printk(); tento řetězec popisuje typ každého "argumentu" (proměnné nebo výrazu v kódu, který je sledován). Když sledovací kód aktivuje značku, poskytne funkci, která se má zavolat, když je značka zasažena, a formátovací řetězec popisující argumenty, které funkce očekává. Kód značek zajistí, že oba formátovací řetězce souhlasí, jinak se značka nepovolí. Problém je, že napsání formátovacího řetězce vyžaduje práci navíc a zapojené druhy specifikuje jen přibližně. Tyto řetězce tedy mohou například jasně říct, že daný argument je ukazatel, ale neříkají nic o tom, na jaký typ se ukazuje.
V reakci na různé snahy tento problém obejít Mathieu Desnoyers (původní autor práce na jaderných značkách) navrhl nový mechanismus nazvaný sledovací body [tracepoints]. Ty umožňují vložit statické sledovací body do jádra jednodušším a typově bezpečnějším způsobem, kterým se kousky skládají dohromady.
S tracepointy musí být každý sledovaný bod deklarován v hlavičkovém souboru mírně ošklivou sadou maker:
#include <linux/tracepoint.h>
DEFINE_TRACE(jmeno_sledovaciho_bodu,
TPPROTO(trace_function_prototype),
TPARGS(trace_function_args));
Tato definice vytvoří nový sledovací bod pojmenovaný jmeno_sledovaciho_bodu. Každá funkce připojená k tomuto sledovacímu bodu musí mít prototyp, který poskytuje makro TPPROTO(); jména příslušných argumentů poskytuje TPARGS().
Pochopitelnější to pravděpodobně bude na příkladu. Patch sledovacích bodů zahrnuje pár statických bodu pro použití se sledovacím toolkitem LTTng. Je zde jeden nazvaný sched_wakeup, který se odpálí pokaždé, když plánovač probudí proces. Je definován takto:
DEFINE_TRACE(sched_wakeup,
TPPROTO(struct rq *rq, struct task_struct *p),
TPARGS(rq, p));
Skutečné vložení sledovacího bodu vypadá takhle:
trace_sched_wakeup(rq, p);
Všimněte si předpony trace_ přidané k dodanému jménu. V tomto bodě lze volat sledovací funkci s parametry rq (běžící fronta, která nás zajímá) a p (proces, který se budí). Nicméně dokud není se sledovacím bodem spojena skutečná funkce, tato deklarace v podstatě znamená no-op. Připojení sledovací funkce se provede voláním:
void my_sched_wakeup_tracer(struct rq *rq, struct task_struct *p); register_trace_sched_wakeup(my_sched_wakeup_tracer);
Funkce register_trace_sched_wakeup() (vytvořená jako část definice DEFINE_TRACE()) spojí dodanou sledovací funkci se sledovacím bodem. Fakt, že je funkční prototyp pro sledovací funkci dodán jako část definice sledovacího bodu, znamená, že překladač může provést důkladnou typovou kontrolu; jestliže prototypy nesouhlasí, překlad selže. A to by na obrátku mělo ukončit ty trapné situace, ve kterých zapnutí sledování způsobí, že systém spadne v plamenech.
Zajímavé je, že sledovací body byly rozmístěny s mnoha mechanismy vyvinutými pro minimalizaci dopadu na čas běhu jaderných značek; zejména nepoužívají kód "okamžitých hodnot". Profilování ukázalo, že vliv sledovacích bodů na výkonnost je tak malý, že téměř nemá cenu přidávat komplexitu vkládání kódu v době běhu. I tak jsou ale známky toho, že někteří jaderní vývojáři budou mít námitky k přidání sledovacích bodů v jejich současné podobě. Vývojáři chtějí podporu sledování - ale ne za cenu menší výkonnosti, i když je tato cena těžko měřitelná.
Nakonec zde máme sadu patchů sledovací háček [tracehook], se kterou se vynořil Roland McGrath. Sledovací háček se zaměřuje trochu jinam; je to v podstatě pročištění způsobu, jakým jádro řeší systémové volání ptrace(). Patche sledovacích háčků se snaží zorganizovat kód sledování procesu (jehož většina závisí na architektuře) na jedno místo, kde se s ním bude možné vypořádat jako s jednotkou.
Sledovací háček je míněn jako první krok směrem k začlenění nové verze kódu utrace. Utrace byl dlouho zamýšlen jako následník současné implementace ptrace(), která má jenom málo obdivovatelů. Narazil ale na mnoho obtíží, takže jeho cesta do jádra byla pomalá. Na nějakou dobu z konferencí úplně zmizel, ale říká se, že nová verze patchů vyjde brzy; Roland poznamenává, že očekává "poněkud energickou odezvu", až k tomu dojde.
Skutečná důležitost přepracování ptrace() je v tom, že je to cesta směrem k integrovaném sledování v jaderném a uživatelském prostoru. A to je samozřejmě jedna z největších vlastností, kterou nabízí DTrace a která ještě není v SystemTapu k dispozici. Dostat sledování z uživatelského prostoru do jádra - obzvláště pokud by mohlo fungovat se sledovacími body vloženými do některých aplikací pro DTrace - by pro Linux byl velký krok kupředu. Mnoho lidí se bude dívat, až se tato sada patchů znovu objeví.
Mezitím by Roland rád viděl kód sledovacího háčku začleněný do 2.6.27. Na párty ale dorazil pozdě a tento kód za sebou nemá žádný čas v linux-next. Není tedy ještě jisté, jestli se sledovací háčky dostanou dovnitř, než se uzavře začleňovací okno, nebo jestli místo toho budou muset počkat na 2.6.28.
Jak je vidět, v oblasti podpory sledování se toho v Linuxu děje hodně. Zdá se, že sledování je myšlenka, jejíž čas teď konečně přišel. Pokud se podaří začlenit zde popsané kousky a sjednotit je do jednoho frameworku a pokud bude dostatečně jednoduché je všechny použít, čas "závidění DTrace" bude u konce. Tato "jestliže" nejsou nicméně nijak malá, je potřeba udělat ještě docela dost práce; doufejme, že současná úroveň snahy vydrží, dokud nebude hotovo.
s jejich začleněním je většina kamer na trhu podporována v Linuxu....ta veta ma malinko anglicky slovosled... s jejich začleněním je v Linuxu podporována většina kamer na trhu., mi zni o neco vic cesky...
vidět data z tohoto sledovacího vodu
co se to stalo několikrát zas sebou…má být zřejmě
několikrát za sebou.
SystemTap zůstává pravděpodobným sledovacím řešením pro Linux…asi by bylo lepší
zůstává pravděpodobným budoucím sledovacím řešením
Text výše uvádí, že kód jaderných statických sledovacích bodů se "téměř nepoužívá". To by se dalo lépe říci jako "vůbec", až na to, že jádro 2.6.27 bude obsahovat uživatele v podobě frameworku ftrace.…možná by bylo srozumitelnější
až na to, že jádro 2.6.27 bude obsahovat framework ftrace, který je používá.
Patch sledovacích bodů zahrnuje pár statických bodu
pár statických bodu
každý další vývojář, (...) je setřesenTomu nerozumím.
Jestli to ale nebude spise tim, ze uzit dprobes bylo sice mozne, ale narocne...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.