Historie
Je neuvěřitelné, jak jeden princip může zcela změnit architekturu OS. Většina úkolů, které systém vykonává, byla dříve řešena pomocí tzv. pollingu. I známý cron démon je v podstatě polling. Co to je? Zjednodušeně řečeno osahávání v pravidelných intervalech. Jenže koho z vás baví každou sekundu kontrolovat, jestli máte ještě stále připojený disk, když jeho odpojení by mohlo vygenerovat událost (event – „ívnt“). Neustálé osahávání stojí čas i energii. Jedním z dodnes nejošklivějších případů pollingu je kontrola vložení CD do mechaniky, protože mechaniky, kdo ví proč, neumí vložení média samy ohlásit.
Co je dbus
Co nám říká popis balíčku: D-BUS je systém zasílání zpráv mezi aplikacemi.
Úžasné. Zve snad váš správce souborů internetový prohlížeč prostřednictvím dbusu na večeři? Asi ne. Tak k čemu to je? Je to právě k tomu, aby se aplikace navzájem nemusely neustále osahávat, ale budily se pouze, pokud jedna druhé chce skutečně něco říci. Tedy zpráva od jedné aplikace vyvolá akci jiné aplikace.
Linux měl a má velké množství jiných podobných mechanismů – COBRA/ORBit (Gnome), DCOP (KDE), SOAP, XML-RPC a XPCOM. Tyto jsou ale oproti DBUS určeny jen na některý specifický úkol. D-BUS se snaží být univerzálním mechanismem zasílání zpráv mezi aplikacemi. V základu se dělí na system a session. Systémová sběrnice je jen jedna a slouží k předávání informací mezi systémovými službami. Session bus je pak určen k povídání aplikací přihlášeného uživatele.
Ref.: D-BUS
Inotify
Inotify je jeden z mechanismů „event driven“ OS. Inotify je vlastnost kernelu; ten při změně inodu – základní struktury souborového systému (ne jen diskového) v Linuxu – vygeneruje událost. Tuto událost může přijmout např. dbus a odeslat ji aplikacím, které se k tomuto typu událostí přihlásí. Tedy např. beaglu, který poté prohledá změněný uzel/soubor a nemusí v pravidelných intervalech procházet a indexovat celý disk. To udělá jen jednou a pak už jen přidává, co se změnilo.
Ref.: inotify
Udev
Přechod na udev byl bolestný a nepříjemný. Jednoduchá struktura statických souborů reprezentujících zařízení v systému byla nahrazena změtí pravidel, ve kterých se vyznat je nad síly mnoha uživatelů. Doba si ale žádá své. Uživatelé chtějí připojovat nejrůznější serepetičky. Chtějí mít na ploše ikonku, když se to připojí, a nechtějí ji tam, když se to odpojí. A nejlíp barevně, a hned pojmenovanou přezdívkou, kterou svému přípojnému miláčkovi dali. Takže tu je udev. A dbus. Kernel tedy přijme přerušení od např. USB řadiče, zahlásí HALu, že přibyl („Zde!“) kus nového HW, HAL skrze dbus upozorní udev a ten vytvoří příslušná zařízení i s přezdívkami, načež udev řekne dbusu, že je vše připraveno. Dbus to pošeptá HALu a ten vykřičí do světa, že „můžeme vytvořit ikonku“. Toho se chytí třeba gnome-volume-manager a vážení přátelé, je to tady – ikonka.
Ref.: udev
HAL
Hardware Abstraction Layer – můra, která se vynořila teprve nedávno, ale úspěšně se rozrůstá. Jednou z ní jistě bude minimálně HAL2000, jinak to totiž není ani možné. HAL je v současnosti démon, který syslí a rozšiřuje informace o HW, které dostává od kernelu. Tyto pak ve formě trochu záhadných UDI (universal device identifier) typu /org/freedesktop/* v dbus prostoru org.freedesktop.Hal předává dál. Podstatné je, že k tomu přidává různé informace o tom, co se se zařízením dá a nedá dělat, případně co se bude dělat, když se zařízení podě… změní jeho stav. A protože zařízení budou v jeho databázi jen přibývat, jsem zvědav, kde to skončí (nejspíš v SQL…).
Co všechno o vás HAL ví, se můžete dozvědět příkazem.
lshal
HAL se snaží taktéž pomáhat s takovými lapáliemi, jako je sleep/suspend/hibernate. Je to tak, ale ledasjaký výrobce a komponenta nejsou úplně „ACPI compliant“, nebo si výrobce vykládá prostě specifikaci jinak než autoři kernelu atd. A tak je občas, zvláště při probouzení, potřeba např. grafickou kartu trochu „nakopnout“, aby se probrala. K tomu slouží tzv. HAL quirks, a bez toho, abyste je dodali vy – uživatelé HW – se funkčního suspend-resume nedočkáte (tedy pokud nemáte osvíceného výrobce HW).
Ref: HAL, HAL quirks
Jak to celé funguje
Jak to funguje jsem již víceméně popsal v části o udev. Teď by to chtělo trochu špehování a podívat se, jak si aplikace mezi sebou povídají. Není nic jednoduššího. Pusťte si
dbus-monitor
strčte ho tam (USB stick do slotu) a kochejte se.
Upstart
Upstart je to taková demonstrace, k čemu ještě by se daly události využít. Upstart je implementace startovacích systémových skriptů, která řeší závislosti mezi službami pomocí událostí a tedy dbusu. Tento nápad vznikl v Ubuntu a doposud je to zřejmě jediná distribuce, která jej využívá. Jeho přínos pro zrychlení startu je totiž diskutabilní, jeho přínos do světa startu OS je ale minimálně zajímavý. O řetězení událostí při startu systému se programátoři snažili už dříve, a tak máme v init skriptech nejrůznější obezličky. A když nic jiného, aspoň je musíme číslovat, a vždycky nám chybí volné číslo tam, kde ho zrovna potřebujeme. Start má spoustu záludností typu: Co nastartovat dřív – síť nebo firewall? Události by část z nich vyřešily, jenže – start systému je velice citlivá… citlivý… citlivé téma. Ne jen tady platí „co funguje, na to nesahej“. Sice má své mouchy, ale nikoho, kdo restartuje systém jednou „za uherák“, zase tak moc netlačí.
Ref: Upstart
Butch Cassidy a Sundance Kit
Kity se to v poslední době začíná jen hemžit. Člověk v tom pomalu ztrácí orientaci. Navíc když je to všechno zamotané do sebe, stojí to za to. K čemu je tedy takový ConsoleKit? K tomu, abyste se na svém počítači mohli střídat se zbytkem rodiny a všem vám fungovala zvuková karta a akcelerace a další legrace.
Čím se asi tak zaobírá consolekit, zjistíte, když si necháte vypsat
ck-list-sessions
Na základě změny stavu dané session pak vyvolá HAL akci na změnu práv k zařízení. Která všechna zařízení má HAL v merku, najdete ve
/var/lib/hal/acl-list
Příkazem
getfacl
na dané zařízení pak zjistíte, kdo všechno má k zařízení jaká práva.
Část řetězce zkusil pěkně shrnout do následujícího obrázku asi největší propagátor celého tohoto kolotoče David Zeuthen (a já jsem si dovolil obrázek trochu počeštit):
z něj je pěkně patrné i to, k čemu je použití PolicyKitu.
Posledním zmiňovaným Kitem bude PackageKit. Nejnovější to přírůstek do rodiny. Jeho autorem je též náruživý kitovec Richard Hughes. Neustálé problémy s kolizemi aktualizací a instalací pomocí nejrůznějších yumů/aptů/smartů atd. ho vedly k nápadu vytvořit univerzální asynchronní frontend, který by byl schopen využívat všechny backendy typu yum bez toho, aby se jich člověk dotkl. Jak se na mnoha místech dočtete, PackageKit není náhrada synapticu a yumexu atd. Je to nástroj, který primárně slouží k řešení situací, které se zatím řešily všelijak nebo špatně:
- aplikace bezpečnostních aktualizací již při startu systému
- automatická instalace chybějících souborů (např. openoffice-clipart)
- instalace nového software podle vloženého nového zařízení
- možnost instalovat aplikace/aktualizace i uživatelům bez administrátorských práv
- instalace aktualizací, i když nikdo není přihlášen
K celému problému přistupuje tak, že vytváří jakousi frontu, do které zařazuje přicházející požadavky, všechno to prohání přes DBUS a je to slušně zamotané.
Krom toho, že PackageKit vytváří i pěkné GUI, má samozřejmě oblíbené CLI rozhraní. Celou jeho krásu si ale budeme moci vyzkoušet až v následujících verzích oblíbených distribucí (např. Fedora 9).
Ref.: ConsoleKit + FastUserSwitching, PolicyKit, PackageKit
Kdo za to všechno může
Především uživatelé. Podívejme se na sebe a řekněte si upřímně: Chtěli jsme to takhle složité? Nestačil nám ten mount a fstab? Nestačil. Tak to máme.
Až zase uvidíte na vašem systému startovat další „zbytečnou“ službu, než ji vypnete, zjistěte, k čemu vlastně je.
Neboť jak je vidět, za poslední roky běžným linuxovým systémem prorostlo téměř neviditelné podhoubí, jehož pochopení je pro toho, kdo to s Linuxem myslí vážně, zcela nezbytné.
Ref.: D-BUS a HAL v jemně postarších článcích Red Hat Magazínu
