Jaderné noviny – 5. 1. 2017: Sledování funkčních závislostí mezi zařízeními

13. 1. 2017 | Redakce | Jaderné noviny | 3944×

Stav vydání jádra. Konec začleňovacího okna 4.10. Sledování funkčních závislostí mezi zařízeními.

Stav vydání jádra

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.

Konec začleňovacího okna 4.10

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:

• Architektura PA-RISC získala podporu pro randomizaci adresního prostoru jádra.
• Začlenění se dočkala sada patchů technologie alokace cache. Zpřístupňuje mechanismus procesorů Intel, díky kterému je možné rozdělit cache mezi různé procesy. Dá se tak zabránit tomu, aby cache obsadila jedna skupina procesů (například kontejner), nebo vyhradit část cache skupině privilegovaných procesů.
• K dispozici jsou nové ovladače pro 25/40/100Gb iSCSI iniciátory QLogic QEDI a hardwarové watchdogy SoC Loongson1.
• Došlo k odstranění typu cycle_t, který se používal pro hodnoty časovačů, z jádra. Nahradil ho obyčejný typ u64.

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).

Sledování funkčních závislostí mezi zařízeními

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.

       

Komentáře

[Harvie.CZ]

Uz sem se lekl, ze mame jadro 5.1, ted koukam, ze to je datum

[aceman]

"Architektura PA-RICS" => PA-RISC?

[Michal]

Me spis prekvapilo ze se tehle obstarozni architekture jeste nekdo venuje. Zajimalo by me co ma za motivaci? HP uz PA-RISC nejakych 10 let nevyrabi, servery se nedaji servisovat, je to pomale, ovladani konzole obskurni, atd. Proc tim nekdo travi cas? Ja pred dvema lety par starych HP-UX serveru s PA-RISC CPUs musel dat do srotu protoze to nikdo nechtel ani zadarmo.

[Fluttershy, yay!]

Někomu to někde běží a náklady na energie jsou menší než nákup nového železa a migrace?

[citanus]

ve sporce to beha urcite. Pred par lety jsem to mel chvilku na starosti. HPUX 11, oracle db.. bezi tam jedna masina, a vedle se vali dve "nahradni kdyby neco" .  Provoz minimalni, maji tam nejaky klienty (radove desitky), kterym dobihaj smlouvy. Ale co vim tak to bezi kvuli povinne archivaci a obcasne potrebe ucta..

[R]

Napriklad preto, ze ten HW niekto ma a bavi ho hrat sa s Linuxom. Tak nieco opravi, vylepsi a dostane sa to do upstreamu. To je rozdiel oproti komercnym OS.

[Michal]

To asi bude ono. A odpor proti jeho patchum od maintaineru bude minimalni protoze PA-RISC port myslim zajima jen hrstku lidi na svete takze je ostatnim spravcum burt kdyz si to pa-riscisti rozbijou ;)

[David]

Tak poslední čip byl uveden v roce 2005 - to je teprve 12 let zpátky.. Myslím, že to bude někdo udržovat ještě spoustu roků ;)

[majvan]

Spravne chapem, ze sa tu riesi zavislost v zmysle "zivotnosti" instancie zariadenia, cize tato zavislost len ovplyvnuje casove poradie volani attach / detach? Alebo co konkretne je tou zavislostou myslene?

[Gilhad]

V podstate ano, ale jde o to, ze kdyz mas pro "fotak" strom zarizeni

• CPU
  • DMA
    • HW jpeg enkoder
      • fotochip
  • I2C
    • zaostrovaci algoritmus
    • porovnavac urovni
      • pomocny snimac ostreni
    • radic motorku ostreni
      • motorky

tak ve chvili, kdy vypnes fotochip, tak nema cenu drzet celou strukturu (az na CPU) zapnutou a muze se vypnout taky, protoze vypinas "fotak", ale pokud mas neco jineho na DMA, nebo I2C, tak jejich radice musi zustat bezet.

Pokud vypnes DMA, tak rovnou muzes vypnout i ostatni zminene (az na CPU a mozna I2C), protoze zase "fotak" nema sanci fungovat a tak nemusi zrat proud.

Coz zatim nejde rozumne popsat, protoze se jen lozi po stromu nahoru/dolu, ale to, ze motorky ostreni a fotochip nejsou na sobe nezavisle tam zapsat nejde.

S nove navrzenym rozsirenim by to slo a dal by se vypnout "fotak" jako celek a nemusel by se vybirat po "nesouvisejicich" castech, protoze by ty casti uz spolu "souvisely"

[Peter Fodrek]

A ono to nejde dnes urobiť?

Ak mám jadro s podporou modulov(nemusím mať a sú prípady, keď ju mať nemôžem)

Tak by som spravil "metamodul" závislý na všetkých komponentoch, tak pri in a out cez modprobe to ide, ja viem modprobe -r má problém s viac ako troma úrovňami.

Ak by som urobil sub moduly bez podpory ACPI/ APM ... a túto funkcionalitu by mal len metamodul s realizoval by ich cez volania symbolov submodulov.

Jediná vec, prečo to má význam, je zjednodušenie prístupu k takto koncipovaným zariadeniam a unifikácia.

[citanus]

co kdyz tam bude vice instanci toho zarizeni? mozna to vyresi parametry pro meta modul moznap ravidla v udev..

[D.A.Tiger]

Myslim, ze to je presne to, cemu se chteji vyvojari jadra timto modelem vyhnout. Kernel se svymi moduly je jako lego, kde kazda kostka - na dane hw konfiguraci - musi perfektne zapadnout do tech ostatnich. Prozatim se to resi zavislostmi mezi moduly. Ty jsou kolikrat zavisle na modulech, ktere se na dane konfiguraci vubec neuplatni ale musi byt jadru - diky tem zavislostem - pritomne (protoze nikdo nedokaze dopredu rict, zda budou ci nebudou potreba). To treba zhatilo moje plany na zbudovani naprosto minimalistickeho plne monolitickeho jadra jen s temi moduly (slinkovanymi s kernelem) , ktere opravdu moje hw. konfigurace vyuzije. Nepocitam "casto" menitelne periferie jako je klavesnice, mys, ci usb zarizeni. Nebylo by fajn kvuli nove klavesnici, ci usb klicence kompilovat znovu kernel.

Pochopil-li jsem to spravne, pak kdyz vezmu ten priklad s kostkami lega, tak strom funkcnich zavislosti je plan jak ty kostky sestavit pro konkretni hw. konfiguraci, podle ktereho by jiz bylo mozno vyradit nepotrebne zavislosti modulu, bez obav, ze se zhrouti zbytek systemu. To by nakonec mohlo vest (napr) k uspesne realizaci meho vysneneho minimalistickeho monolitickeho jadra....