Portál AbcLinuxu, 14. května 2025 14:59
Stav vydání jádra. Dynamické události pro sledování funkcí.
Kernel release status. Jonathan Corbet. 21. února 2018
Současné vývojové jádro je 4.16-rc2, vydané 18. února. „Jděte a testujte, vypadá to dobře.“
Stabilní aktualizace: 4.15.4, 4.14.20, 4.9.82, 4.4.116 a 3.18.95 byly vydány 17. února. (Velké) aktualizace 4.15.5, 4.14.21, 4.9.83 a 4.4.117 byly v době psaní článku revidovány a vyšly 23. února.
Dynamic function tracing events. Jonathan Corbet. 15. února 2018
Co jádro obsahuje sledovací body, vývojáři se dohadují, zda jsou tyto sledovací body součástí ABI jádra. Změny sledovacích bodů už v minulosti musely být vráceny, protože rozbíjely již existující programy v uživatelském prostoru, které na nich začaly záviset. Mezitím obavy ze zafixování interního kódu v určitém stavu komplikovaly přidávání sledovacích bodů do řady jaderných subsystémů. Nyní je na stole návrh funkcionality, která by všechny tyto problémy obešla.
Otázka, zda jsou sledovací body součástí jaderného ABI, není nepodstatná. Příslib spojený s jaderným ABI říká, že funkční programy nebudou rozbity aktualizací jádra. Časem se vyjasnilo, že tento příslib se vztahuje i na sledovací body. Na povrch to vyplulo nejpatrněji v roce 2011, kdy změna sledovacího bodu rozbila powertop a musela být vrácena do původního stavu. Někteří jaderní správci zakazují nebo výrazně omezují přidávání sledovacích bodů do svých subsystémů, protože se obávají, že by se jim mohlo stát něco podobného jako v případě powertopu. V jádře tím pádem chybí sledovací body, které by se uživatelům mohly hodit.
Tato tématika se dostala na program mnoha setkání včetně Summitu správců 2017. Tehdy padl chytrý nápad: vývojáři, místo aby na citlivá místa umísťovali sledovací body, by prostě používali značky, které by se za běhu musely explicitně připojit a převést na sledovací body. Doufalo se, že nutnost vyrovnat se s několika překážkami navíc by způsobila, že nový mechanismus by nevytvářel taková očekávání stability ABI. Pak téma na několik měsíců vyšumělo.
Nedávno se ale vynořil správce sledování Steve Rostedt s variantou původního návrhu, kterou nazývá „dynamicky vytvářené události založené na funkcích“. Podrobnosti se změnily, ale princip vyhnutí se ABI zůstává v zásadě stejný. Klíčový detail, který se výrazně liší, vychází z postřehu, že jádro už disponuje jistým druhem značek, jenž by se pro účely sledování dal použít.
Jaderný kód je obvykle překládán s volbami, které se běžně používají při profilování kódu. Tím pádem každá funkce začíná voláním funkce nazvané mcount() (nebo v případě novějšího překladače __fentry()__). Při profilování programu v uživatelském prostoru sleduje mcount() volání jednotlivých funkcí a kolik času se přitom zabere. Jádro ale nahrazuje mcount() vlastní variantou, která oplývá schopnostmi jako sledování funkcí. Většinou se volání mcount() patchi zcela odstraní, ale dají se povolit za běhu, když je potřeba sledovat volání určité funkce.
Jsou i další možná využití této vazby při vstupu do funkce. Rostedtův patch ji používá, aby umožnil vytvoření sledovacího bodu na začátku libovolné jaderné funkce za běhu. Po připojení ovládacího souborového systému tracefs jde nový sledovací bod vytvořit příkazem jako tento:
echo 'SyS_openat(int dfd, string path, x32 flags, x16 mode)' \
> /sys/kernel/tracing/function_events
Tento příkaz si vyžádá vytvoření sledovacího bodu při vstupu do SyS_openat(), jaderné implementace systémového volání openat(). Sledovací bod bude hlásit čtyři hodnoty: deskriptor souboru adresáře (dfd), danou cestu (path) a argumenty flags a mode. Tento sledovací bod se zobrazí v events/functions a bude vypadat jako jakýkoliv jiný sledovací bod v jádře. Půjde se na něj obvyklým způsobem dotazovat a povolit/zakázat ho. Co je zajímavé, v tomto případě míří path do uživatelského prostoru, ale sledovací systém i přesto data získá a vytiskne.
Zjevně zatím není veškerá práce na této záležitosti hotova: „Musím přepsat sledování grafů funkcí a musím být schopen přidávat dynamické události při návratu z funkce.“ Ale ústřední část už je, zdá se, tam, kde má být, a funguje. Tím pádem ale zbývá jedna podstatná otázka: stačí to, abychom se vyhnuli vytvoření nové skupiny jaderných rozhraní, která by se stala součástí stabilního ABI? Mathieu Desnoyers se obává, že nikoliv:
Ten problém nezmizí mávnutím kouzelného proutku, ani když budeme mít tyhle nástroje navázané na jména/argumenty funkcí. Jakmile se kód jádra změní, rozšířené nástroje na analýzu sledování se začnou kácet jeden po druhém a budeme tam, kde jsme byli. S tou výjimkou, že tentokrát se součástí ABI stane interní hlavička funkce.
Avšak Linus Torvalds s touto obavou nesouhlasil. Krok navíc, který by byl nutný k navázání se do jádra, vede k jinému pohledu na pozici takové vazby:
Všichni *rozumějí*, že to je jako debugger: když máte gdb skript, který zobrazuje nějaké informace, a změníte zdrojový kód, pak *samozřejmě* budete muset upravit i ten skript debuggeru. Zdrojový kód neudržujete neměnný, jenom abyste udělali radost svému gdb skriptu. To by bylo přihlouplé.
Na druhé straně lidé opravdu uvěřili, že explicitní sledovací body mají v dlouhodobém časovém horizontu nějaký smysl.
Pokud tento úhel pohledu odpovídá realitě, nový mechanismus dynamických sledovacích bodů by mohl významně pomoci rozptýlit problémy s ABI. Množství nových pevných sledovacích bodů v jádře by se nejspíš zmenšilo, protože vývojáři by mohli jednoduše přejít na dynamickou variantu. Když se v budoucnu přidají obvyklé sledovací body, budou nejspíš navrženy tak, aby podporovaly nějaký nástroj na správu systému, takže by mohly být od samého začátku považovány za součást ABI.
Přitom se pochopitelně předpokládá, že tato řada patchů bude nakonec začleněna. Alexei Starovoitov tomu trochu odporoval, stěžoval si, že nové rozhraní skoro nic nového nepřináší oproti tomu, co jde již nyní dělat s kprobes. Nelíbilo se mu ani textové rozhraní a (ne zrovna překvapivě) navrhoval k tahání určitých kousků informací z jádra spíše používat BPF. Rostedt ale poukázal, že mnoho vývojářů odrazují složité začátky s BPF, a tak by preferovali něco jednoduššího.
Rostedt řekl, že rozhraní považuje za užitečné, ale nebude v jeho vývoji pokračovat, pokud ostatní nesouhlasí: „Pokud si ostatní myslí, že by to bylo přínosné, byl bych rád, kdyby se ozvali.“ Zatím se vyjádřilo několik málo lidí. Jestli si další vývojáři myslí, že by mechanismus pro dynamické sledování funkcí byl užitečný, mohli by o svém postoji dát vědět.
Kéž by to bylo tak jednoduché. Nejde samozřejmě o to, že by někdo pořádal demonstrace, ale o to, že zvládnout eBPF (ne, nebavíme se o tom starém jednoduchém BPF) do té míry, aby ho člověk dokázal použít pro konkrétní účel, znamená nemalou (časovou) investici. Když člověk řeší nějaký bug, tak je obvykle rychlejší a jednodušší si vybuildit testovací jádro, kam narve nějaký ten trace_printk(). Až získá, co potřeboval, tak se zase bude věnovat něčemu jinému a za čas se situace bude opakovat. Ani nepočítám, kolik nástrojů už mám na pomyslném seznamu "na co se podívám, až bude čas" (třeba takový quilt už je tam asi sedm let).
Nastudovat si, jak použít kprobe na to, abych se podíval na parametry funkce, to je řekněme dvacet minut poprvé a pak třeba pět pro dohledání podrobností, až to budu potřebovat časem znovu (pokud to nebudu potřebovat tak často, že si to radši zapamatuju). Budu-li potřebovat něco složitějšího, co nepůjde bez eBPF, jsou ty časy někde úplně jinde, takže se nelze divit, že většina raději sáhne po jiném řešení. Demonstrovat na náměstí nepůjdou, ale tu featuru prostě nepoužijí.
Můžete s tím nesouhlasit, můžete na to nadávat, můžete je přesvědčovat, ale to je asi tak všechno, co se s tím dá dělat. Stačí se podívat, jak absurdní výmluvy spousta lidí dodnes používá k ospravedlnění toho, že ještě po 19 letech používají ifconfig, route nebo netstat.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.