Portál AbcLinuxu, 22. května 2024 04:48
Stav vydání jádra. Konec začleňovacího okna 4.10. Sledování funkčních závislostí mezi zařízeními.
Současný vývojový kernel 4.10-rc2 byl vydán 1. ledna. Od 4.10-rc1 z 25. prosince bylo začleněno pouze 27 nových patchů.
Stabilní aktualizace: od 15. prosince žádné nevyšly. Stabilní aktualizace 4.9.1, 4.8.16 a 4.4.40 byly v době psaní tohoto článku v procesu revidování, vydány byly 6. ledna.
Začleňovací okno 4.10 bylo podle očekávání uzavřeno 25. prosince vydáním verze 4.10-rc1. Nakonec bylo pro toto vydání do hlavního repozitáře začleněno 11 455 neslučovacích sad změn, čímž se tento vývojový cyklus zařadil k těm rušnějším, i když nebyl tak rušný jako 4.9. Téměř 400 změn bylo začleněno po vydání shrnutí z 22. prosince, tudíž je jejich seznam poměrně krátký.
Ze seznamu změn:
Stabilizační fáze cyklu 4.10 začala vzhledem ke svátkům později. Mezi verzemi 4.10-rc1 a 4.10-rc2 bylo aplikováno pouze 27 neslučovacích sad změn. Dá ale se předpokládat, že tempo vzroste, jakmile se vývojáři vrátí do práce a přiblíží se finální datum vydání 4.10 (pravděpodobně 12. nebo 19. února).
Výpočetní systémy od dob, kdy Linux vznikl, výrazně nabyly na složitosti. Jádro na to reagovalo vývojem nových mechanismů pro správu složitosti zařízení, včetně modelu ovladačů, dynamického přidělování čísel aj. Tyto mechanismy vyřešily spoustu problémů, ale přestože je problém správy závislostí mezi zdánlivě nezávislými zařízeními za běhu znám již delší dobu, řádného řešení se mu dostalo až v začleňovacím okně 4.10.
Některé závislosti zařízení jsou nedílnou součástí architektury systému. Například periferie připojené přes USB budou nepoužitelné, není-li k dispozici odpovídající hostitelský USB adaptér, který je nejspíš připojen k jiné systémové sběrnici, která musí být rovněž v provozu. Závislosti založené na topologii propojení v systému jsou relativně jednoduše reprezentovatelné stromovou strukturou: k tomu byl jaderný model zařízení vytvořen. Při použití tohoto modelu může jádro např. uspat zařízení v systému ve správném pořadí a zároveň udržovat zprostředkující zařízení v provozu, dokud nedojde k vypnutí všech ostatních zařízení, která na nich závisí.
V moderních systémech však může být graf závislostí poněkud složitější. Například „zařízení“ reprezentující fotoaparát pravděpodobně tvoří skupina vzájemně propojených zařízení, která jádro vidí jako nezávislá. Ve skutečnosti ovládání fotoaparátu vyžaduje senzor, pravděpodobně ovládaný přes sběrnici I2C, asi také závisí na několika GPIO zařízeních, která se starají o napájení a restartovací linky. Senzor je připojen k samostatné sběrnici zařízení, která získává obrazová data: tato sběrnice může potřebovat DMA řadič k přesunu dat do paměti. Součástí mohou být také další zařízení pro různé transformace obrazu (např. rotace nebo konverze barevného prostoru) implementované hardwarově.
Jde o to, že každou z těchto složek jádro vnímá jako samostatné zařízení. Tato zařízení přísluší samostatným řadičům a možná jsou na samostatných sběrnicích – z pohledu topologie systému nejsou nijak příbuzné. Ve většině případů je do funkčního celku seřadí nějaký nadřazený řadič. Informace, které k tomu potřebuje, se v dnešních systémech nacházejí ve stromové struktuře zařízení. Jenže jádro jaderných ovladačů něco může pokazit vypnutím některého z podřazených zařízení, když neví, že další zařízení na něm závisejí.
Ovladače dosud měly tendenci tento problém obcházet pomocí jednorázového kódu unikátního pro každé zařízení. Jak by se dalo očekávat, takové řešení vede k časté duplikaci kódu a spoustě polovičatých řešení. Bylo by mnohem lepší mít jedno řešení v jádře kódu ovladače, a to by fungovalo pro všechna zařízení. Posun k takovému řešení je cílem infrastruktury funkčních závislostí, která byla začleněna pro vydání 4.10.
Rozhraní tohoto mechanismu je celkem jednoduché, skládá se z jediné funkce, která indikuje existující závislost:
struct device_link *device_link_add(struct device *consumer,
struct device *supplier,
u32 flags);
Toto volání informuje jádro ovladače, že zařízení consumer závisí na zařízení supplier. Takže systém kupříkladu neuspí zařízení supplier, dokud není uspáno i zařízení consumer, a nepokusí se přistupovat k zařízení consumer nebo ho znovu spustit, dokud nepoběží supplier. Navíc, pokud bude zařízení supplier uvolněné (unbound), dojde k automatickému uvolnění i zařízení consumer, protože to by beztak nebylo schopno nadále fungovat.
Vazby mezi zařízeními jsou implicitně perzistentní a zůstanou v platnosti po dobu běhu systému. Pokud ovšem se při vytvoření vazby objeví příznak DL_FLAG_AUTOREMOVE, k automatickému odstranění vazby dojde tehdy, když je ovladač zařízení consumer uvolněný. Tyto neperzistentní vazby mohou být užitečné v situacích, kdy je možné hardware nastavit více způsoby a v průběhu času vytvářet různé závislosti. Příznak DL_FLAG_STATELESS se dá použít k vytvoření vazby pro seřazení při uspání/probuzení, o kterou se ale jinak jádro ovladače nestará.
Pokud je třeba explicitně odstranit vazbu zařízení, dá se tak učinit pomocí volání device_link_del():
void device_link_del(struct device_link *link);
Stav k vydání 4.10-rc2 je takový, že hlavní větvi jádra se tato nová infrastruktura využívá pouze na jednom místě (kód části pro správu paměti I/O SoC Exynos). Dá se však očekávat, že další využití se objeví během následujících vývojových cyklů. S trochou štěstí je bude doprovázet úbytek objemu kódu pro řízení závislostí v jednotlivých ovladačích a také celkové zlepšení kvality jádra.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.