Byl vydán Mozilla Firefox 125.0.1, první verze z nové řady 125. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout lze podporu kodeku AV1 v Encrypted Media Extensions (EME). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 125.0.1 je již k dispozici také na Flathubu a Snapcraftu.
Valkey, tj. svobodný fork již nesvobodného Redisu, byl vydán v první stabilní verzi 7.2.5.
Společnost Espressif Systems oznámila, že rodinu SoC ESP32 brzy rozšíří o ESP32-H4 s IEEE 802.15.4 a Bluetooth 5.4 (LE) s podporou protokolů Thread 1.3, Zigbee 3.0 a Bluetooth Mesh 1.1.
Kevin Bentley zveřejnil na GitHubu zdrojové kódy počítačové hry Descent 3 z roku 1999: "Někdo se nedávno zeptal, zda budou zveřejněny zdrojové kódy Descent 3. Oslovil jsem svého bývalého šéfa (Matt Toschlog) z Outrage Entertainment a ten mi to povolil. Budu pracovat na tom, aby se to znovu rozběhlo a hledám spolusprávce." [Hacker News]
Byla vydána verze 0.81 telnet a ssh klienta PuTTY. Opravena je kritická bezpečnostní chyba CVE-2024-31497 obsažena ve verzích 0.68 až 0.80. Používáte-li klíč ECDSA NIST P521 a použili jste jej v PuTTY nebo Pageantu, považujte jej za kompromitovaný.
Hra MineClone2 postavena nad voxelovým herním enginem Minetest byla přejmenována na VoxeLibre.
Společnosti Avast Software s.r.o. byla pravomocně uložena pokuta ve výši 351 milionů Kč. Tu uložil Úřad pro ochranu osobních údajů za neoprávněné zpracování osobních údajů uživatelů jejího antivirového programu Avast a jeho rozšíření internetových prohlížečů (Browser Extensions), k čemuž docházelo prokazatelně po část roku 2019.
… více »Bylo vydáno do češtiny přeložené číslo 714 týdeníku WeeklyOSM přinášející zprávy ze světa OpenStreetMap.
V sobotu 20. dubna lze navštívit Maker Faire Jihlava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Knihovna pro potlačení šumu RNNoise byla vydána ve verzi 0.2. Kvalitu potlačení lze vyzkoušet na webovém demu.
Současné vývojové jádro je 2.6.36-rc2 vydané Linusem 22. srpna. Obsahuje hlavně opravy, ale Linus také přetáhl některé malé části sady patchů škálovatelnosti VFS. Další velké začlenění je v -rc2 aktualizace grafických karet Intelu. Nejsem zrovna nadšený z načasování, ale myslím, že bylo potřeba to přetáhnout. Krom toho je tu spousta různých oprav všude možně, přiložený zkrácený changelog napoví víc. Detaily vizte ve zmíněném zkráceném changelogu, v kompletním changelogu najdete všechny informace.
V době psaní tohoto článku bylo od vydání 2.6.36-rc2 začleněno přibližně 200 změn. Většinou se jedná o opravy, ale také je zde nový ovladač pro ethernetové řadiče Marvell pxa168 a změna mutexů (vizte níže).
Stabilní aktualizace: Jádra 2.6.27.52, 2.6.32.20, 2.6.34.5 a 2.6.35.3 byla vydána 20. srpna. Jedná se o relativně malé aktualizace obsahující opravy nové vlastnosti „ochranná stránka zásobníku“, která byla přidána kvůli nedávno zveřejněné slabině umožňující lokální získání roota pomocí X.org.
V současnosti se reviduje větší sada aktualizací; lze ji očekávat po 26. srpnu.
-- James Bottomley (díky Jodymu Belkovi)
napsal Jonathan Corbet, 25. srpna 2010
Jaderný mutex je spící zámek; vlákno, které prohraje zápas o zabrání specifického mutexu, je zablokováno, dokud mutex není k dispozici. To přinejmenším říká dokumentace; skutečnost je o trochu komplikovanější. Zkušenosti ukazují, že propustnost systému jako celku lze občas zvýšit tak, že se procesy čekající na zámek neuspí okamžitě. Konkrétně pokud (1) vlákno zjistí, že mutex není k dispozici a (2) držitel mutexu v současnosti běží, vlákno bude čekat v cyklu, dokud mutex nebude k dispozici nebo do zablokování držitele. Toto „optimistické“ čekání v cyklu umožňuje přenést mutex bez průchodu cyklem uspání/probuzení a, což je důležité, mutex je předán běžícímu (tzn. má data v cache) vláknu. Výsledek není férový, ale dosahuje vyšší výkonnosti.
Až na to, že se ukázalo, že výkonnost není vždy vyšší. Když testoval na 64jádrovém systému, všiml si Tim Chen problému: Naráz může na jeden mutex čekat více vláken. Jakmile je k dispozici, jenom jedno z vláken čekajících v cyklu ho zabere; ostatní budou dál čekat v cyklu a soupeřit o něj. Obecně je optimismus dobrý, ale přílišný optimismus škodí, pokud vede k chování, které nevrací užitečné výsledky. A zdá se, že to je ten případ zde.
Tim zareagoval patchem, který mění implementaci optimistického čekání. Ve smyčce se nyní navíc kontroluje, jestli se nezměnil vlastník mutexu. Pokud se tak stalo, zatímco vlákno čekalo, znamená to, že mutex byl někým uvolněn a někdo jiný ho zabral dřív. Jinými slovy se o tento mutex značně soupeří a více CPU běží v cyklu a závodí o to, které vyhraje. V takových případech dává větší smysl prostě se uspat a čekat, dokud se věci trochu nezklidní.
Různé benchmarky ukázaly významný nárůst výkonnosti v situacích, kdy se značně soupeřilo. To bylo dostatečné k tomu, aby se patch dostal do 2.6.36-rc2.
napsal Jonathan Corbet, 25. srpna 2010
Jedním z temnějších koutů jaderného subsystému pro správu paměti je příznak __GFP_NOFAIL. Tento příznak říká, že danému požadavku na alokaci není dovoleno selhat bez ohledu na to, jestli paměť je k dispozici, nebo není; jestliže požadavek nelze uspokojit, alokátor začne běžet ve smyčce a doufat, že se situace nějak změní. Není třeba říkat, že jaderným vývojářům není příliš doporučeno tento příznak používat. Nedávno se ho David Rientjes pokoušel zbavit tak, že vytlačí (potenciálně) nekonečnou smyčku k volajícím.
Andrewa Mortona patch nepřesvědčil:
David reagoval tak, že zmínění zlosynové nebyli opraveni během několika let a _GFP_NOFAIL vynucuje komplexitu v alokátoru stránek, která způsobuje zpomalení pro všechny uživatele. Andrew reagoval návrhem na vytvoření zvláštních verzí alokačních funkcí, které by se staraly o smyčku; to by implementaci odstranilo z vnitřních částí alokátoru, ale stále by to umožnilo najít kód, který je potřeba opravit; David se tomu podřídil a přidal kmalloc_nofail() a spol.
U takového patche je garantováno, že přiláká komentáře od těch, kteří mají pocit, že je mnohem lepší prostě opravit kód, který není připraven vyrovnat se se selháním alokace paměti. Jak ale upozornil Ted Ts'o, to není vždycky snadné:
Ted upozorňuje na to, že vždy budou místa, kde bude zotavení ze selhání alokace poměrně obtížné nebo úplně nemožné. Jádro tedy může buď poskytnout prostředky, s nimiž čekání ve smyčce při selhání proběhne na jednom místě, nebo se taková místa objeví náhodně po celém jádře. Špatný kód nezmizí tak, že se zamete pod kobereček, takže se zdá pravděpodobné, že centrální mechanismus smyčky při selhání bude existovat navždy.
napsal Jonathan Corbet, 24. srpna 2010
Je výjimkou, když Linus před otevřením začleňovacího okna mluví o tom, co se chystá začlenit v daném vývojovém cyklu; zdá se, že preferuje podívat se na požadavky na přetažení a pak teprve se rozhodnout. V oznámení 2.6.35 ale udělal výjimku:
Těžko se najde vývojář, který by po takových slovech brzdil začlenění svých změn, Nick ale chtěl, aby patche ještě jeden cyklus počkaly, pravděpodobně kvůli zcela racionálním obavám z chyb, které by mohly naštvat uživatele. Linus si tedy na svůj kód s vyhledáváním cest pomocí RCU bude muset počkat. Některé části kódu pro škálovatelnost VFS se nicméně do hlavní řady dostaly v 2.6.36-rc2.
Jako ve většině případů z poslední doby je i práce na VFS zaměřena na to, aby se pracovalo lokálně a CPU nemusela sdílet zdroje. Vzhledem k tomu, že souborový systém je z principu globální struktura, zajištění lokální práce může být poměrně velká výzva; výsledkem je, že část Nickovy sady patchů je poměrně složitá a záludná. Nakonec se ale všechno týká toho, aby se s věcmi pracovalo lokálně, když je to možné, ale stále bylo možné pracovat globálně, když je to potřeba.
První krok je zavedení dvou nových typů zámku, první z nich se nazývá lokální/globální zámek (lgzámek) [local/global lock]. Lgzámek má poskytnout velmi rychlý přístup k datům specifickým pro CPU a zároveň umožnit (s trochu většími náklady) dostat se k datům jiného CPU. Lgzámek se vytvoří pomocí:
#include <linux/lglock.h> DEINE_LGLOCK(jmeno);
Makro DEFINE_LGLOCK() je 99řádkový zázrak, který vytváří potřebné datové struktury a přístupové funkce. Z návrhu vyplývá, že lgzámky mohou být vytvořeny pouze na globální úrovni; není zamýšleno, aby se mohly vkládat do jiných datových struktur.
Pro práci se zámkem se používá další sada maker:
lg_lock_init(name); lg_local_lock(jmeno); lg_local_unlock(jmeno); lg_local_lock_cpu(jmeno, int cpu); lg_local_unlock_cpu(jmeno, int cpu);
Pod tím vším je lgzámek jenom pole spinlocků specifických pro CPU. Volání lg_local_lock() zabere spinlock současného CPU, zatímco lg_local_lock_cpu() zabere zámek patřící specifickému cpu. Zabrání lgzámku také vypne preempci, což by se jinak v jádrech pro běh v reálném čase nestalo. Dokud většina zamykání probíhá lokálně, bude velmi rychlé; zámek nebude poskakovat mezi CPU a nebude se o něj soupeřit. Oba tyto předpoklady jsou samozřejmě mimo hru, když se použije verze pro více CPU.
Občas je nutné lgzámek zamknout globálně:
lg_global_lock(jmeno); lg_global_unlock(jmeno); lg_global_lock_online(jmeno); lg_global_unlock_online(jmeno);
Volání lg_global_lock() projde celé pole a zabere spinlock každého CPU. Není potřeba říkat, že se jedná o velmi drahou operaci; pokud k tomu bude docházet častěji, lgzámek pravděpodobně není vhodné primitivum. Verze _online zabírá zámky jenom pro CPU, která běží, lg_global_lock() je zamkne pro všechna možná CPU.
Se sadou patchů škálovatelnosti VFS se také vrací koncept „velkého čtenářského zámku“ [big reader lock]. Myšlenkou brzámku je umožnit co nejrychlejší zamykání pro čtení, ale přitom umožnit zamykání pro zápis. API brzámku (také definované v <linux/lglock.h>) vypadá takto:
DEFINE_BRLOCK(jmeno); br_lock_init(jmeno); br_read_lock(jmeno); br_read_unlock(jmeno); br_write_lock(jmeno); br_write_unlock(jmeno);
Není překvapivé, že tato verze brzámků je implementována zcela pomocí lgzámků; br_read_lock() je přímo mapována na lg_local_lock() a br_write_lock() se mění na lg_global_lock().
První použití lgzámků chrání seznam otevřených souborů, které jsou připojeny ke každé struktuře superbloku. Tento seznam je v současnosti chráněn globálním files_lock, ze kterého se stane úzké hrdlo, když se hodně používají volání open() a close(). V 2.6.36 se ze seznamu otevřených souborů stává pole specifické pro CPU, kde každé CPU spravuje vlastní seznam. Když je soubor otevřen, k ochraně lokálního seznamu, když se přidává nový soubor, stačí (levné) lg_local_lock().
Když se soubor uzavírá, je to o něco komplikovanější. Nikde není garantováno, že soubor bude v seznamu lokálního CPU, takže VFS musí být připravena podívat se do seznamů ostatních CPU a úklid provést tam. K tomu samozřejmě slouží lg_local_lock_cpu(). Zamykání více CPU bude dražší než lokální zamykání, ale (1) týká se jenom jednoho dalšího CPU a (2) v situacích, kde se hodně otevírají a zavírají soubory, je velmi pravděpodobné, že proces, který pracuje se specifickým souborem, se během té (pravděpodobně krátké) doby do jeho uzavření nepřestěhuje na jiné CPU.
Důvodem pro existenci seznamu otevřených souborů pro superblok je, aby jádro mohlo najít všechny zapisovatelné soubory, když se souborový systém přepíná do režimu pouze pro čtení. Tato operace vyžaduje exkluzivní přístup k celému seznamu, takže je nutné použít lg_global_lock(). Globální zámek je drahý, ale změna režimu připojení není tak běžná, takže si toho pravděpodobně nikdo nevšimne.
V 2.6.36 Nick také změnil globální vfsmount_lock na brzámek. Tento zámek chrání seznam připojených souborových systémů; je potřeba ho zabírat (pouze pro čtení), kdykoliv vyhledávání cesty překročí z jednoho připojení do jiného. Přístup pro zápis je potřeba, pouze když se souborové systémy připojují nebo odpojují – což opět není na většině systémů běžná operace. Nick varuje, že tato změna pravděpodobně většinu zátěží nezrychlí – naopak může některé trochu zpomalit – ale její hodnota se projeví, když se vyřeší další úzká hrdla.
Kromě dalších malých změn tady práce na škálovatelnosti VFS ve vývojovém cyklu 2.6.36 končí. Složitější záležitosti – konkrétně vyřešení dcache_lock – budou muset projít několika dalšími měsíci testování, než je bude možné tlačit do hlavní řady. Pak bude Linus možná spokojen.
napsal Jake Edge, 25. srpna 2010
Přidat rozhraní, pomocí kterého by uživatelský prostor mohl přistupovat k jadernému crypto subsystému – a také k hardwarové akceleraci, pokud je k dispozici – vypadá na první jako rozumný nápad. Jenže přidat velký kus kódu, který původně byl v uživatelském prostoru, do jádra, aby se implementovaly další kryptografické algoritmy včetně šifrovacích systémů s veřejným klíčem, pravděpodobně nebude tak jednoduché. K tomu je API založeno na ioctl() a obsahuje ukazatele a data proměnné velikosti, což bariéru ještě zvyšuje. I tak ale existují dobré argumenty pro to, aby subsystém crypto nějaké rozhraní pro uživatelský prostor poskytoval, i když současný návrh nevyhovuje.
Miloslav Trmač zaslal sadu RFC patchů, které implementují rozhraní pro uživatelský prostor /dev/crypto. Kód je odvozen od cryptodev-linux, ale novou implementaci z větší části vyvinul Nikos Mavrogiannopoulos. Sada patchů je poměrně velká, hlavně protože začleňuje dvě knihovny pro uživatelský prostor – jedna pracuje s celými čísly s násobnou přesností (LibTomMath) a druhá přidává dodatečné šifrovací algoritmy (LibTomCrypt); celkem nějakých 20 000 řádek. To je současná implementace, i když se objevila zmínka o přechodu na něco, co je založené na Libgcrypt, o které se tvrdí, že je lépe kontrolována a aktivněji udržována; o moc menší ale není.
Jednou z klíčových výhod tohoto nového API je, že s klíči lze pracovat zcela v jádře, což uživatelskému prostoru umožňuje šifrovat i dešifrovat, aniž by se klíč předal aplikaci. To znamená, že chyby v aplikacích by nemohly způsobit vyzrazení klíče. Klíče by také bylo možné v jádře obalit, takže by aplikace obdržela zašifrovaný blob, který by se uložil na trvalé úložiště a po rebootu zase načetl do jádra.
Ted Ts'o celý tento nápad zpochybnil, obzvláště tu část, jestli by hardwarová akcelerace opravdu věci zrychlila:
Také se mu zdálo, že práce s klíči je redundantní: Jestliže je cílem přistupovat ke klíčům uschovaným v hardwaru, nemáme pro to již nyní rozhraní pro TPM? [Trusted Platform Module, modul důvěryhodné platformy]. K tomu ale Nikos poznamenal, že jedním uživatelem této práce mají být embedded systémy, kde hardwarová verze AES může být stokrát rychlejší než softwarová. Také řekl, že rozhraní TPM nebylo dostatečně flexibilní a že jedním cílem nového API je, aby ho bylo možné obalit modulem PKCS #11 [Public-Key Cryptography Standard pro kryptografické klíče] a transparentně používat dalšími šifrovacími knihovnami (openssl/nss/gnutls), což rozhraní TPM neumožňuje.
V jádře je již nyní podpora pro správu klíčů, takže Kyle Moffet by chtěl, aby se použila: Již nyní máme v jádře hezké API pro klíče/klíčenky [keyrings] (viz Documentation/keys.txt), které se používá pro šifrovací klíče pro NFSv4, AFS atd. Nemohl bys prostě přidat spoustu typů cryptoapi klíčů k tomuto API? Nikos si myslí, že když toto API umožňuje export klíčů do uživatelského prostoru – což /dev/crypto explicitně zakazuje – nebylo by to vhodné. Vývojář David Howells k tomu navrhuje jednoduchý způsob, jak tento problém obejít: Tak k danému typu klíče neposkytuj operaci read().
Rozhraní samo o sobě ale také přitáhlo nějaké stížnosti. Aby mohla /dev/crypto použít, musí aplikace zařízení otevřít (open()) a pak používat ioctl() volání. Každá ioctl() operace (jsou pojmenovány NCRIO_*) má svůj vlastní typ – strukturu – která se předává jako datový parametr:
res = ioctl(fd, NCRIO_…, &data);
Mnoho struktur obsahuje ukazatele na uživatelská data (vstupní i výstupní), které jsou deklarovány jako ukazatele na void. Z toho vyplývá nutnost používat compat_ioctl, aby se vyřešily záležitosti ohledně 32 a 64bitových ukazatelů, s čímž nesouhlasí Arnd Bergmann: Nové ovladače by měly být napsány tak, aby se vyhýbaly voláním compat_ioctl a jako ioctl příkazy používaly pouze velmi jednoduché datové struktury s daty pevné velikosti. Myslí si, že by se v rozhraní neměly používat ukazatele, pokud je to jenom trochu možné: Ideálně bys měl používat ioctl k ovládání zařízení a k předávání dat používat read a write.
Krom toho rozhraní také přimíchává atributy o délce proměnných ve stylu netlink, kterými podporuje věci jako výběr algoritmu, inicializační vektor, typ klíče (tajný, soukromý, veřejný), algoritmus obalení klíče, mnoho dodatečných atributů, které jsou specifické pro algoritmus (např. délka klíče) či specifické hodnoty pro RSA a DSA. Ty všechny lze předat v poli párů (struct nlattr, data atributu), přičemž se používá stejné formátování jako u netlink zpráv; pole lze přidat na konec struktury specifické pro operaci u většiny – ale ne všech – operací. Ve zkratce se jedná o složité rozhraní, které je rozumně dokumentováno v prvním patchi série.
Arnd a další mají také obavy ze začlenění všeho toho kódu navíc:
Nikos si myslí, že přínosy převažují nad riziky spojenými s přidáním kódu, přirovnává to k existujícím šifrovacím a kompresním nástrojům v jádře. Rozdíl je, jak upozorňuje Arnd, že jádro tyto nástroje používá samo, takže v něm být musí. Kód, který je zde přidáván, slouží striktně k podpoře uživatelského prostoru.
V úvodu patche Miloslav vyjmenovává mnoho argumentů pro přidání dalších algoritmů do jádra a pro poskytování API pro uživatelský prostor, většina z nich se týká různých vládních nařízení, která vyžadují oddělení poskytovatele šifrování a uživatele. Záměrem je držet klíče oddělené od - pravděpodobně zranitelnějších – programů v uživatelském prostoru, i když to by šlo zajistit i jinými způsoby, například pomocí démona běžícího pod rootem v uživatelském prostoru, který by zmíněnou funkcionalitu poskytoval, což je v úvodu také zmíněno. Zde je ale obava, že dělat to takto by mělo příliš velkou režii: to by bylo mnohem pomalejší kvůli přepínání kontextu, chybným rozhodnutím plánovače a režii spojené s IPC. Nebyla však poskytnuta žádná čísla, která by konkrétně ukázala, jak velká režie navíc to bude.
V API je mnoho zajímavých schopností hlavně pro práci s klíči. Dostatečně privilegovaný program by mohl nastavit hlavní AES klíč pro subsystém, tímto klíčem by se potom šifrovaly a obalovaly klíče před předáním do uživatelského prostoru. Žádná práce s klíči se nezachovává při rebootu, takže uživatelský prostor bude muset zajistit ukládání všech klíčů, které vygeneroval. Použití hlavního klíče to umožňuje, aniž by uživatelský prostor dostal přístup k něčemu jinému, než je zašifrovaný blob.
Rozhraní zpřístupňuje všechny očekávatelné operace: šifrování, dešifrování, podepisování a ověřování podpisu. Každá operace je přístupná pomocí sezení [session], které se inicializuje pomocí ioctl() NCRIO_SESSION_INIT. Následuje žádné nebo více volání NCRIO_SESSION_UPDATE a závěrem je NCRIO_SESSION_FINAL. Pro operace na jedno použití je také NCRIO_SESSION_ONCE, které všechny tři předchozí operace provede v jednom volání.
I když se zdá, že je toto rozhraní dobře promyšlené a obsahuje prostor, jak pracovat s nepředvídanými algoritmy s odlišnými požadavky, je také velmi složité. Když odhlédneme od oddělení klíčů a rychlejšího šifrování u embedded zařízení, neposkytuje toho mnoho uživatelům desktopů či serverů a přidává ohromné množství kódu a s tím spojené břemeno údržby. V současné podobě lze jenom těžko předpokládat, že se /dev/crypto dostane do hlavní řady, ale některé nápady, které implementuje – obzvláště pokud se lépe integrují do existujících jaderných funkcí – by začleněny být mohly.
napsal Jonathan Corbet, 24. srpna 2010
Jedna věc, kterou má na starosti jádro, je sběr statistik. Pokud někdo chce vědět, kolik multicast paketů bylo přijato, ke kolika výpadkům stránky došlo, kolikrát došlo ke čtení disku nebo kolik přerušení bylo přijato, jádro má odpověď. Tato role běžně není zpochybňována, ale za poslední dobu se objevilo několik návrhů, že řešení statistik by se mělo trochu změnit. Výsledkem je změna toho, jak by se měly z jádra získávat informace – a nějaké zajímavé otázky ohledně ABI.
V červenci Gleb Natapov zaslal patch, který mění způsob, jak se řeší stránkování v hostech virtualizovaných pomocí KVM. Patch obsahoval sbírání několika nových údajů o výpadcích stránky na každém virtuálním CPU. O více než měsíc později (virtualizace věci zpomaluje) Avi Kivity patch revidoval; jeden z jeho návrhů je:
Tuto radu nikdo nezpochybnil. Možná je to kvůli tomu, že mnoha vývojářům virtualizace přijde nudná, ale také to naznačuje širší trend.
Tímto trendem je samozřejmě stěhování sběru a zpracování dat z jádra do susbystému „událostí výkonnosti“ [perf events]. Je to jenom rok, co se perf objevil ve vydaném jádře, ale od té doby je na něm patrný nepřetržitý vývoj a růst. Podle některých vývojářů nakonec vnitřní jádro bude jenom obskurním kusem kódu, který tam musí zůstat, aby perf fungoval.
Přesun sběru statistik do sledovacích bodů přináší zjevné výhody. Pokud nikdo statistikám nevěnuje pozornost, žádná data se nesbírají a režie je téměř nulová. Když lze zachytit jednotlivé události, lze zkoumat jejich korelaci s ostatními událostmi, analyzovat časování, zachytávat související data atd. Dává tedy smysl exportovat samotné události a ne převařit je do malé sady čísel.
Nevýhodou používání sledovacích bodů je to, že již není možné zjistit statistiky zjištěné během celého běhu systému. Jak odpozoroval Matt Mackall více než před rokem:
Autor článku si zde myslí, že většinou vývojáři a správci pozorují změny čítačů a nepotřebují součet od počátku. Jsou zde ale případy, kdy je taková informace užitečná. Přibližnou hodnotu by bylo možné zjistit povolením sledovacího bodu při bootu a nepřetržitým sběrem událostí, ale to může být náročné – obzvláště u často se opakujících událostí.
Také je zde další důležitá záležitost, která byla v minulosti zmíněna a která nikdy nebyla dořešena. Sledovací body se obvykle považují za podpůrné nástroje používané hlavně vývojáři jádra. Často jsou navázány na nízkoúrovňové implementační detaily; změny v kódu často vynutí změny blízkých sledovacích bodů, nebo je úplně zneplatní. Jinými slovy sledovací body bývají téměř tak nestálé, jako jádro, do kterého jsou osazovány. Jádro se rychle mění, takže je vcelku očekávatelné, že sledovací body se budou také měnit rychle.
Není třeba říkat, že změna sledovacích bodů způsobí problémy aplikacím v uživatelském prostoru, které tyto sledovací body používají. Jaderní vývojáři zatím širší používání sledovacích bodů nedoporučovali; jádro jich zatím mnoho nemá a jak bylo zmíněno výše, jsou to hlavně ladící nástroje. Jestliže ale nahradí jaderný sběr statistik, počet programů v uživatelském prostoru, které je budou používat, může jenom narůst. A to povede k odporu k patchům, které takové sledovací body změní a programy rozbijí.
Jinými slovy se sledovací body stávají součástí ABI pro uživatelský prostor. Přestože obavy ze statusu sledovacích bodů, co se ABI týče, nebyly v minulosti vyřešeny, tato změna podle všeho přichází zadními dveřmi zcela bez plánování. Jak v minulosti upozornil Linus, fakt, že nikdo sledovací body neoznačil jako oficiální ABI a nedokumentoval je, na věci nic nemění. Jakmile se rozhraní zveřejní pro uživatelský prostor a začne se šířeji používat, je součástí ABI bez ohledu na záměry vývojáře. Jestliže nástroje v uživatelském prostoru budou sledovací body používat, jaderní vývojáři je budou muset udržovat donekonečna.
Z minulých diskuzí vzešly návrhy, jak označit sledovací body, které jsou míněny jako stabilní, ale žádné závěry z nich nevzešly. Situace je tedy nadále zamlžená. Tak to možná zůstane, dokud nějaká budoucí změna jádra nerozbije něčí nástroj; pak se jaderná komunita bude muset rozhodnout mezi obnovením kompatibility rozbitého sledovacího bodu, nebo otevřeně porušit svůj dlouhotrvající slib, že se ABI pro uživatelský prostor nebude rozbíjet (příliš často). Možná by bylo lepší věci vyřešit dřív, než se do takového bodu dostaneme.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czs/DEINE/DEFINE/
7.9.2010 14:30
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
7.9.2010 18:07
Jendа | skóre: 78
| blog: Jenda
| JO70FB
9.9.2010 08:41
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
