Spěje Linux k microkernelu?

9.7.2006 00:03 | Přečteno: 1499× | Software

Zejména v poslední době pozoruji, že mi v systému rychlým tempem přibývají jaderné procesy. Neskončí to nakonec tak, že se Linux dostane (i když jinou cestou) tam, kam se měl původně dostat Hurd?

Když jsem začínal s GNU/Linuxem, bývalo jádro prakticky mrtvým kódem, jak odpovídalo původní unixové filosofii. Systém tehdy využíval pouze dva procesy: bdflush pro zpožděný zápis na disk, a swapd (?) pro virtuální paměť na disku. Později pár procesů přibylo (už si přesně nevzpomínám které), ale stále to bylo skoro stejné.

S příchodem řady 2.6 se roztrhl pytel s novými procesy jádra. Ostatně rozhraní pro pracovní fronty, přenos událostí do userlandu a další podobné věci přímo vybízejí k tomu, aby se věci realizovaly prostředníctvím procesového kódu, tedy v podstatě démonů (nebo jinak řečeno "serverů"). Již od počátku řady běžela normálních distribučních jádrech celá řada procesů. Prakticky s každou další verzí procesy přibývaly, a mám pocit, že se přírůstky stále zvětšovaly.

U aktuálního jádra (2.6.17) jsem v reálu napočítal 18 jaderných procesů, a to nepočítám běžné démony jako udevd nebo hald (o mnohých dalších nemluvě), které také vydatně slouží jádru (resp. systému jako celku). Zejména mě upoutal nový démon kpsmoused, který se stará o data z myši připojené přes PS/2. Narozdíl od většiny ostatních takových procesů totiž spravuje jedinou třídu zařízení, což je docela průlomová věc (nepočítám-li některé dosavadní workaroundy pro nestandardní hardware).

Jedná se tedy zcela zřetelně o odklon od jádra s monolitickou (byť modulární) architekturou a postupný přechod na architekturu mikrojádra. Bude zajímavé sledovat, do jaké míry se autoři různých linuxových ovladačů zařízení vydají také touto cestou. Pokud by byl přechod skutečně houfný, brzy by se Linux dostal tam, kde měl být Hurd. Pouze cesta by byla naprosto odlišná - evoluce místo revoluce.

Uživatelů GNU/Linuxu se tato změna přímo nijak nedotýká. Z celkového pohledu by se však jednalo o změnu pozitivní, protože by se zmenšil objem kritického kódu a stabilita systému by mohla být vyšší. Otevřelo by to tedy cestu Linuxu i tam, kde jsou kvůli jeho architektuře zatím obavy z možných rizik. Nechme se překvapit, zatím to vypadá nadějně.

       

Komentáře

[Käyttäjä 11133]

Možná by si toto téma zasloužilo podrobněji rozebrat, nechcete někdo něco napsat?

[Luk]

Já už radši nic neslibuji. Již v tuto chvíli něco dlužím a nerad bych, aby se to rozrostlo

[Kyosuke]

Dokud tam nebude wgad nebo mswgad, bude to dobrý...

[Pavel Stárek]

Spíš lkgad, tedy linux kernel genuine advantage daemon a k němu v userlandu patřičný notifikátor a v balíčcích distribucí balíčky s názvem lkga-tools s prioritou required

[Pavel 'lingeek' Szalbot]

O tomhle se diskutovalo už před čtyřmi lety, možná i dříve. Nedávno navíc téma mikrokernelu znovu "ožilo" a objevily se linky do archivů mailing-listů či rozhovorů s Linusem na dané téma. Za všechny např. Linux, the microkernel (linux-kernel archiv), Slashdot...

[brk]

Píšeš tam kpsmoused. Nevíš náhodou, kdy se to přesně „trhlo“ a co to všechno může ovlivnit? Zrovna od 2.6.17 mi začala zlobit myš. Někdy se se po (re)bootu nechytne a je potřeba znovu rebootovat, takže jsem se vrátil k 2.6.16, což ale z dlouhodobého hlediska není řešení. Když jsem koukal do changelogu 2.6.17, tak jsem tam nějaké myšácké záznamy viděl.

[Luk]

Je to od 2.6.16, ve verzi 2.6.17 se změnilo pouze zamykání (přechod od semaforu k mutexu). Ale já osobně jsem žádné problémy s myší nezaznamenal, na nové řešení jsem přišel čistě náhodou tak, že jsem narazil na ten nový proces.

Kdyžtak to reportuj jako bug, problém může být i jinde než v tomto ovladači.

[knizmi]

Mám na svém Debianu ten samý problém - s jádrem 2.6.17 mi nejde myš. Teď jedu na 2.6.15 a všechno v pohodě. Zatím mě to moc netrápí, ale až časem budu chtít upgradovat...

[fakenickname]

Skvělý zápis, hned bych zhltnul ještě pokračování.

[zde]

Mikrokernel deleguje funkcionalitu na PROCESY, které mají separátní adresové prostory (tj každý task switch na ně zruší dobrou tisícovku cpu cyklů, spláchne tlb a někdy i L1 cache, a provede spoustu dalších ošklivých věcí).

Kernelové thready jsou nepoměrně menší zlo, a za krok k MK to myslím nepovažovat nejde, jde "jen" o těch 8kB neswapovatelné paměti v ha***u.

[Luk]

Nemá smysl řešit, zda by šlo o "čistý" mikrokernel se vším všudy, nebo něco, co se mu blíží (ostatně ani "monolitické" jádro nebylo úplně monolitické).

O tu neswapovatelnou paměť až tolik nejde, není jí zase tolik vzhledem ke dnešním velikostem pamětí.

Mnohem důležitější věcí (kterou jsem asi nedostatečně zdůraznil), je přínos stabilitě systému. Když se kousne handler přerušení nebo tasklet (ať už v nekonečné smyčce, špatným zacházením se zámky apod.), je vymalováno - jádru nepomůže ani svěcená voda. Kdežto když stejný kód (který nepotřebuje být časově kritický) běží jako proces, klidně v adresním prostoru jádra, jeho zákus není pro zbytek systému zničující. "Pouze" přestane fungovat ta jediná věc, jinak se nic moc neděje.

Takže ano, tento přístup má sice své nedostatky, ale také nesporné a podstatné přednosti. Proto si myslím, že to není špatný trend.

[zde]

Podle toho jak já chápu většinu definicí MK, tak právě oddělení adresových prostorů je to, kde se láme chleba; nutnost komunikovat přes message passing, poměrně náročná validace zpráv, oddělení procesů a jejich plánování, to vše jsou už jen důsledky. Jestli jsou kernelové thready cestou k MK, tak je to dosti velkou oklikou (IMHO).

Linux se dnes hodně tlačí na embedded platformy, a tam je stále každých 8kB poměrně hodně; i když tam bude task_struct a IPC možná výrazně efektivnější než na x86 - nevím.

Ad robustnost: Jo, to je asi pravda. Když se zacyklí kernel thread, je to menší problém než když se zacyklí bottom half. Ale obsluha HW by především neměla tuhnout na zacyklení, skoro všude jsou stejně timeouty. A když už, myslím že podobnou věc by šlo realizovat i bez kernel threadů; jednoduše by se nastavoval timeout před voláním každého BH, a když by se zacyklil, tak se jednoduše longjmp()em vyskočí, a ten handler se vyhodí ze seznamu.

[zde]

ad patička: Troubil bych tak dlouho, dokud to auto co jede 30 nezrychlí nebo nezastaví nebo dokud neujedeme ty 4km.

[Luk]

Gratuluji k úspěšnému složení zkoušky ze zákona 361/2000 Sb. ve znění zákona 411/2005 Sb.

Podplukovník Bambas by z tebe měl radost