DragonFly BSD
Před jistou dobou došlo ve vývojovém teamu FreeBSD k jistým rozepřím, jejichžvyústěním bylo zbavení tzv. commit bitu prominentního vývojáře Matthew Dillona.Matthew nelenil a začal pracovat na něčem co v červnu 2003 oznámil pod jménem DragonFly BSD.
DragonFly je operační systém UNIXového typu vycházející z FreeBSD 4.x (tj.podobný vývoj jako u OpenBSD vycházejícího z NetBSD), který se snaží naplňovatstejné cíle jako FreeBSD 5.x ovšem podstatně jinak. Systém je momentálně vevelmi počátečním stádiu vývoje, ale už se vyznačuje několika zajímavýmyvlastnostmi. Navíc se na léto tohoto roku plánuje vydání verze 1.0 a tak jemyslím vhodné se s tímto systémem seznámit.
Matthew Dillon vyrůstal v prostředí počítačů Amiga, které měli na svou dobuvelmi progresivní design. Byly to přirozeně paralelní NUMA stroje (když se topojmenuje dnešnímy slovy). Amiga měla různé autonomní subsystémy a několikrůzných disjunktních (tj. ne cachujících se) paměťových (mám na mysli operační paměť) prostorů. To si vyžádalo určitý přístup k operačnímu systému (který se v80. letech vyznačoval preemptivním multitaskingem apod.!). Matt je tímto velmiovlivněn a své zkušenosti uplatňuje při designování DragonFly.
Vývoj dnešních počítačů se silně zaměřuje na paralelní architektury. Konvenčnízpůsoby zvyšování výkonu počítačů už neposkytují takový potenciál a jedináživotaschopná cesta se zdá býti v paralelismu. Je sice možné, že se objeví jinéarchitektury než je Von Neumannova s Turingovým CPU, ale na to se nedá spoléhat(byť by to bylo krásné). Proto se klade stále větší důrazu na věci jako je multithreading, multiprocesoring atd. Empirickým důkazem budiž vývoj v Linuxu,FreeBSD, rozvoj Gridů či jen implementace hyperthreadingu u Intelu.
FreeBSD řady 5 řeší problém multiprocesoringu za pomocí takzvaného jemnéhozamykání. To znamená, že každá sekce má vlastní zámek, který chrání její datapřed nekonzistencí. To sebou přináší problémy se správným zamykáním, protožejen velmi těžké toto implementovat bezchybně. Chyby se navíc objevují vpodstatě náhodně. Dalším problémem je velké množství práce, které je nutné prosamotnou obsluhu zámku. DragonFly toto řeší jinak - každý proces je svázán s jedním určitým CPU a nemůže být preemptivně přenesen na jiné. Tím se eliminuje nutnost zamykání (stačí kritické sekce). Pokud je nutné migrovat proces je k tomu využit mechanismus posílání zpráv. Pošle se zpráva o migraci procesu aproces je migrován. DragonFly implementuje primitiva pro posílání zpráv a je snaha toto používat pro vše.
Je plánováno změnit tradiční systém syscall tabulky na čisté posílání zpráv stím, že v userspace bude \"emulační vrstva\" která se postará o překladtradičních systémových volání na posílání zpráv. Toto bude mít výhodu vmožnosti měnit libovolně kernel API. Výhodou je, že userspace programy nekomunikují s kernelem přímo, ale přes nějakou vrstvu, takže nemusí znátstrukturu kernelových dat. Tj. zbavíme se #ifdef KERNEL v include souborech aps nám bude fungovat i po výměně kernelu (bez rekompilace).
Další věcí je VFS, které má být změněno tak aby jako svůj středobod bralojména souborů místo jejich vnodes a aby operovalo na základě zpráv. Při nějakéIO operaci to tedy bude vypadat tak, že se resolvne jméno ze stromu, zjistí sek čemu je příslušné (který VM object to obsluhuje) a dále se operuje s těmitoúdaji. Tím se docílí toho, že kernel nebude operovat s VM údaji z userspace (=více bezpečnosti) a že při n (n>1) referencích na stejný soubor bude totoreferencováno jen jednou. Samotná IO operace může probíhat v několikaparalelních threadech. VFS se výrazně zjednoduší, protože nebude muset být taksilně chráněno různýmy mutexy (bude používat zprávy).
Zajímavým způsobem se má řešit čtení/zápis (cachování). Principielně jde o MESIs tím, že se daný soubor (jsme v UNIXu všechno je soubor) rozdělí (dle sférzájmu) na n různých VM objectů nad kterýmy bude operovat n threadů paralelně.Za pomoci zpráv je pak možné provádět kolapsy/slučování VM objectů apod. Pokudby se toto podařilo bylo by to úžasné, nicméně osobně si myslím, že to nepůjde,protože data jsou na sobě většinou lineárně závislá a navíc pořád platí principlokality. Nehledě na to, že se bude muset hlídat tolik různých podmínek, žefakt nevim. Ale snad se mýlím a půjde to ;
Poslední zajímavou věcí jsou variant symlinky. Ty jsou docela lehceimplementovatelné kvůli změnám v VFS (referencuje se jméno ne vnode). Na nichje založen systém instalace softwaru (je to BSD tj. kompletní OS). Veškerýsoftware (za pomoci varsymlinků) uvidí jen ty verze knihoven/softwaru kterépotřebuje. Tj. budete mít /lib/libabc.so a pro program xyz to bude verze 1.2.3a pro klm to bude verze 3.2.1... docela cool
Na DragonFly se mi líbí, že má vše positivní z FreeBSD 4.x + spoustu vylepšeníz 5.x (RCng, ATAng, AMD64 support, GCC 3.x atd. atd.). Z unikátních vlastnostíse mi zatím líbí checkpointing - uspání procesu, jeho uložení na disk a obnovav libovolném jiném čase na libovolném jiném stroji. Také se chystá import XFS(což je ostatně i v FreeBSD) změna sysinstallu apod. Další super věc je jak jeten projekt živý, pořád se objevují nové nápady, lidé jsou nadšení, zapálenípro věc, oproti FreeBSD fakt změna. Všem vám doporučuji se na DragonFly podívatwww.dragonflybsd.org, také je fajn sledovat vývoj nawww.shiningsilence.com/dbsdlog.
neologism
P.S. DragonFly jsem nikdy neviděl a veškeré informace jsem získal z mailinglistů a další dokumentace.neologism
