Portál AbcLinuxu, 6. května 2025 00:02
Aktuální verze jádra: 2.6.24-rc7. Citáty týdne: Al Viro, Ted T'so. 2.6.24 - trocha statistik. Linux trace toolkit - nová generace.
Aktuální předverze je 2.6.24-rc7, vydaná 6. ledna, Obsahuje slušnou řádku oprav a také implementaci /proc/slabinfo pro alokátor SLUB. O dlouhé době mezi vydáním jednotlivých verzí Linus Torvalds řekl: Budu shovívavě tvrdit, že to je kvůli stabilizaci a ne kvůli tomu, že byli přes prázdniny všichni namol. Krátký changelog je součástí oznámení; podrobnosti najdete v dlouhém.
V hlavním git repozitáři je v tuto chvíli už několik desítek patchů pro -rc7.
Aktuální stabilní verze jádra řady 2.6 je 2.6.23.13, vydaná 9. ledna. Tato aktualizace bude zajímat jen uživatele ovladače w83627ehf pro monitorování hardwaru. Greg KH k tomu řekl: Přišla mi soukromá zpráva, že by tahle chyba mohla způsobovat trvalé poškození hardwaru. V současné době pro to nemám definitivní důkaz, ale naneštěstí to kvůli nedostatku dokumentace nemohu vyloučit.
Starší jádra: 2.6.16.58-rc1 vyšlo 6. ledna s přibližně desítkou oprav, z nichž některé se týkají bezpečnosti.
A co zaručí, že k tomu nedojde, ještě než se dostaneme ke zpětnému volání? Pokud vím, tak vůbec nic...
A když se to stane, tak se rdev uvolní (pomocí rdev_free(), coby ->release() &rdev->kobj), než se dostaneme k delayed_delete(). Což všechno krásně vysvětluje.
-- Al Viro ukazuje, jak debugovat problémy v jádře.
Skutečnost, že se mohu na plný úvazek věnovat práci na Linuxu, považuji za velké štěstí. Ale pokud tobě to tak nepřipadá, tak přijmi mou upřímnou soustrast a dělej to, co těší tebe.
-- Ted Ts'o předvádí, jak trollům odpovídat na úrovni.
Vydání 2.6.24 už se blíží [v době vydání JN už jádro 2.6.24 vyšlo] - i když je pravděpodobné, že se ještě dočkáme jedné -rc. Tempo změn se však výrazně zpomalilo a dochází k odstraňování posledních regresí. Je tedy příhodná chvíle se podívat na patche, které se do jádra dostaly, a kde se vzaly.
Tentokrát jde, hned v mnoha směrech, o rekordní vývojový cyklus. Doposud bylo začleněno přes 10 tisíc sad změn a přibylo skoro 300 tisíc řádků kódu. Tímto kódem přispělo 950 vývojářů, z nichž 358 poslalo jen jeden patch. Pro srovnání: v předchozím cyklu (2.6.23) bylo začleněno přibližně 6200 patchů od 860 vývojářů. Není tedy překvapivé, že příprava 2.6.24 trvala déle.
Podívejme se tedy na seznam přispěvatelů:
Nejaktivnější vývojáři 2.6.24 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Podle obou způsobů počítání vychází jako vítěz Thomas Gleixner kvůli jeho práci na sjednocení architektur i386/x86_64. Dát tyto architektury dohromady a zařídit, aby výsledek fungoval, to byl velký úkol; práce bude pokračovat i v nadcházejících vývojových cyklech. (Pro zvědavé: pouze přejmenované soubory nebyly při počítání brány jako "změněné řádky".) Spoustu těch patchů také podepsal Ingo Molnár, ale git ukládá jako autora sady změn jen jedno jméno.
Mezi další přispěvatele s velkými počty změn patří Bartlomiej Zolnierkiewicz (hodně patchů v ovladačích IDE), Adrian Bunk (úklid ve všech částech jádra), Ralf Baechle (práce na architektuře MIPS), Pavel Emelyanov (především jmenné prostory sítí a PID), Tejun Heo (SATA a čistky v sysfs), Johannes Berg (bezdrátové síťování) a Al Viro (hlavně anotační patche a související opravy). Když se podíváte na počet změněných řádků, tak se seznam vývojářů skoro úplně změní: Zhu Yi (ovladač iwlwifi), Auke Kok (ovladač e1000), Michael Buesch (bezdrátové síťování a ovladač b43), Ivo van Doorn (bezdrátový ovladač rt2x00), Matthew Wilcox (SCSI, hlavně ovladače advansys a sym53c8xx), Adrian Bunk (čistky a mazání kódu), Larry Finger (hlavně přidání staršího ovladače b43) a David Miller (síťování a SPARC64).
Pokud přiřadíte příspěvky vývojářů zaměstnavatelům, vypadá tabulka takto:
Nejaktivnější zaměstnavatelé | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
V mnoha směrech vypadají tyto seznamy podobně jako ty u předcházejících jader [viz 2.6.22 a 2.6.23]. Několik věcí se však tentokrát liší:
Podtrženo sečteno, u přispěvatelů do jádra 2.6.24 bylo identifikováno přibližně 130 různých zaměstnavatelů. To je hodně společností, které pracují na jednom projektu.
Pohled na položku Signed-off-by [podepsal] je vždycky zajímavý; odstraníme-li podpisy, které přidali samotní autoři, tak získáme seznam "vrátných" - těch, kteří kód směrují do jádra. Následuje přehled lidí, kteří podepsali nejvíce patchů, které sami nenapsali:
Podpisy v 2.6.24 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Oproti předchozím vývojovým cyklům došlo k mnoha změnám. Ačkoliv je poměrně dost vývojářů, kteří kód podepíší a předají dál, pracují pro malý počet firem - 7 zaměstnavatelů pokryje 70 % neautorských podpisů.
A konečně, protože začíná nový rok, měli bychom se podívat na celý uplynulý rok 2007. V roce 2007 Linus začlenil více než 30 000 sad změn (více než 80 denně) od 1900 vývojářů, kteří pracovali pro (přinejmenším) 200 firem. Změnilo se přes 2 milióny řádků kódu a jádro se rozrostlo o 750 000 řádků. Jinými slovy, vývojáři denně sáhnou na průměrně 5 000 řádků kódu - to je vysoké tempo změn. Nejaktivnější přispěvatelé (podle sad změn) byli:
Nejaktivnější v roce 2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Sluší se poznamenat, že čísla u zaměstnavatelů jsou o něco hrubější než obvykle. Někteří vývojáři v průběhu roku změnili zaměstnavatele, ale LWN z principu neudržuje databázi vývojářů a jejich zaměstnavatelů. I tak je obrázek relativně neměnný - některé společnosti dlouhodobě přispívají přibližně stejným počtem patchů.
Celkově lze říci, že je z těchto čísel poznat zdravá a široce rozšířená vývojářská komunita. Nevypadá to, že by byl nedostatek pracovních příležitostí pro vývojáře jádra, ale je tu i místo pro ty, kdo nepracují z kanceláře. Tisíce lidí pracují na vylepšování jádra a nezdá se, že by se v budoucnosti mělo něco měnit.
Jonathan Corbet by za pomoc se zlepšováním těchto statistik rád poděkoval Gregovi KH.
Zařídit, aby běžící jádro umělo debugovat nebo profilovat, to by si přálo hodně administrátorů a vývojářů. Stoupenci OpenSolarisu rádi ukazují na DTrace jako na funkci, které se Linuxu nedostává, i když SystemTap zkracuje náskok. Linux Trace Toolkit next generation (LTTng) využívá jiný přístup a nedávno byl navržen k začlenění do jádra (dva patche: nezávislý na architektuře a závislý na architektuře).
LTTng spoléhá na jaderné značkovače [kernel markers], které mají poskytnout sadu statických kontrolních bodů [probe points] pro sledování aktivit jádra. K dispozici je i možnost sledování uživatelských programů a kombinování těchto dat s údaji o sledování jádra, přičemž výsledkem má být detailní pohled na vnitřnosti systému. Na rozdíl od jiných nástrojů LTTng co možná nejefektivněji ukládá data k pozdějšímu zpracování. To je rozdíl oproti DTrace a SystemTap, které mají oba své vlastní minijazyky, které určují, co dělat, když se dosáhne jednotlivých kontrolních bodů.
Jedním ze základních designových cílů LTTng je mít co nejmenší vliv na systém - nejen když probíhá sledování, ale i když je vypnuté. Vývojáři jádra jsou dost rezervovaní vůči debugovacím řešením, která ovlivňují výkon, i když nejsou používána. Kromě toho by jakékoliv výrazné prodlevy při používání sledování mohly změnit chování systému natolik, že by se studovaná chyba nebo situace neprojevila. Proto jde LTTng jinou cestou než různá dynamická sledovací řešení - vyhýbá se režii přerušení používáním statických značkovačů.
Dalším zásadním požadavkem je poskytovat pro události rovnoměrně vzrůstající časová označení. Původní LTT používá časové značky [timestamps] odvozené z jaderného času založeného na Network Time Protocol (NTP), který může kvůli úpravám kolísat - někdy dokonce i dozadu. LTTng používá časové značky odvozené z hardwarových hodin, které fungují na různých architekturách procesorů a rychlostech hodin. Navíc mohou být časové značky na víceprocesorových systémech porovnávány mezi jednotlivými procesory.
Když LTTng shromažďuje své údaje, používá relayfs pro přenos dat uživatelskému démonu (lttd), který je zapisuje na disk. Démon je spouštěn prostřednictvím nástroje lttctl, jenž ovládá nastavení sledování v jádře přes netlink soket. Uživatel může použít lttctl pro spuštění nebo zastavení sledování; jakmile je sledování dokončeno, je možné data prohlédnout a analyzovat.
LTT prohlížeč (LTTV) je program, který se používá k analýze sebraných dat. K dispozici je GUI i textové rozhraní - obě varianty interpretují binární data, která generuje LTTng, a ukazují je uživateli. Při používání nástroje LTTng nejsou mnohagigabajtové soubory ničím neobvyklým, takže pro vizualizaci a filtrování, aby se mohl uživatel zaměřit na konkrétní události, je nástroj jako LTTV nezbytný. LTTV podporuje pluginy, takže si uživatelé mohou vyvinout vlastní zobrazovací a analytické nástroje, ale používat přitom filtrovací možnosti LTTV.
Výhodou používání statických kontrolních bodů (i když v tom někdo může spatřovat nevýhodu) je skutečnost, že mohou být spravovány zároveň s jaderným kódem, pro který jsou určeny. Pokud by byl začleněn patch s jadernými značkovači, mohly by subsystémy přidávat kontrolní body na místa, která by je zajímala, a tyto značkovače by pak zůstaly v kódu a byly by aktualizovány zároveň se změnami kódu. Jiná řešení spoléhají na srovnávání externího seznamu bodů s verzí běžícího jádra, což může mít za následek chybná přiřazení a nesprávná sledování. Navíc bude moci začleněné značkovače používat i SystemTap, takže uživatelé, kteří by mu dali přednost, by na tom také vydělali.
LTTng je vyvíjen na École Polytechnique de Montréal za podpory několika linuxových společností. Vypadá to jako dobře promyšlený systém, který staví na práci, jež byla v oblasti sledování udělána už dříve. Určitě se nedostane do 2.6.24, ale vypadá to, že by mohl mít dobrou šanci se prosadit v některém z pozdějších vývojových cyklů.
prgramů → programů
O odstavec dál cestoy → cestou
Předposlední odstavec uživatelé, kteří by mu dali přednost, by na to také vydělali → na tom
(alespoň předpokládám, i když věta s „to“ má zajímavý význam w83627ehf
... nachází se podobný problém s případnou destrukcí HW i v jádře 2.6.22.13? Případně bude tento problém v řadě 2.6.22.XX odstraněn také?
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.