GCC 2.95 na nová jádra 2.6 končí
Od debat v LKML před téměř půl rokem (kdy se psalo, že GCC 2.95 bude podporováno ještě dlouho) se přechází k činům a podpora překladače GCC legendární řady 2.95 pro překlad jádra řady 2.6 se chýlí ke konci. Záplatu pro její odstranění zaslal v půli prosince překvapivě velký zastánce tohoto překladače Andrew Morton a zároveň odstartoval diskuzi o konkrétní (minimální) verzi GCC řady 3.x, kterou by mělo jádro podporovat (3.0 určitě ne a 3.1 s největší pravděpodobností také ne). Důvody jsou zřejmé, verze 2.95 je dnes již zastaralá (je z roku 1999) a problematická (stále více kódu nejen v jádře jím nelze přeložit) a bránící dalšímu vývoji. Navíc prakticky všechny (větší) linuxové distribuce přešly na GCC verze 3.x (nebo dokonce 4). Prvním jádrem bez oficiální podpory překladu překladačem GCC 2.95 bude nejspíš verze 2.6.16. To samozřejmě neznamená, že nová jádra nebude možné starým překladačem přeložit.
Bezproblémový překlad verzí 2.95 byl po dlouhá léta (zvláště pro starší řady 2.2 a 2.4) přímo vyžadován, vývojáři jej odmítali opustit, protože jej vyžadovaly některé architektury a překlad byl rychlejší než u novějších verzí. Poslední dobou bylo ale stále obtížnější upravovat nový kód tak, aby byl přeložitelný touto verzí, jiný se neupravoval vůbec. Problémy jsou např. s proměnlivým počtem parametrů funkcí, anonymními uniony nebo expanzí maker. V diskuzi se probírá hlavně (negativní) dopad na architektury, které novější GCC již nepodporují (typicky embedded systémy a zařízení). Tak či tak, pro překlad novějších jader řady 2.6 jsou stejně již delší dobu doporučovány verze GCC novější než 3.2 včetně (pro experimentální sadu záplat -mm Andrew Mortona dokonce vyžadovány).
Mutexy v jádře?
Jádro operačního systému musí umožňovat synchronizaci akcí, které vykonává. Například vykonání jedné akce před jinou, omezení současného využívání chráněného prostředku (kusu sdílené paměti, nějakého hardwaru, apod.), kritické sekce vykonávání a další synchronizační scénáře. Linuxové jádro používá pro synchronizaci (plně) čítající semafor. Tento semafor si lze představit jako počítadlo a lze na něm provádět dvě základní operace - down a up. Volání down volajícího uspí, dokud semafor neobsahuje kladnou hodnotu a po probuzení sníží tuto hodnotu o 1, volání up zvýší hodnotu semaforu o 1 a to případně vyvolá probuzení jednoho uspaného procesu. V jádře se ale semafor většinou nevyužívá jako počítadlo, ale jen jako zámek (mutex), kdy semafor nabývá jen hodnot 0 nebo 1.
Jednoduchý binární mutex by se ale dal implementovat jednodušeji než čítající semafor. Navíc linuxové implementace semaforů jsou specifické pro každou architekturu a jakákoliv změna je velmi složitá. Pokusem o implementaci mutexu je záplata Davida Howellse, která ale, kromě toho, že může být občas pomalejší než původní semafory, což by se dalo napravit, znefunkčňuje kód mimo hlavní strom zdrojových kódů jádra (jiné deklarace funkcí semaforů). Vývojářům (a zvláště Linusovi) se nelíbí, že mutexy používají funkční rozhraní semaforů, raději by viděli nové rozhraní jen pro mutexy.
Taková je implementace odvozená z mutexu v ,,realtime preemption balíku -rt'' Ingo Molnara (viz zprávička v srpnovém
čísle). Navíc jsou jeho mutexy také (správně) výrazně rychlejší než semafory. Rozbor implementace semaforů potom
ukázal, že jejich implementace pro architekturu x86 skrývá nežádoucí možnost probuzení dvou procesů, kterou ovšem nelze
odstranit! V budoucnu tedy můžeme očekávat nějakou implementaci mutexu v jádře, a možná právě tu Ingovu.
Zdroj: www.kernel.org
