Forrás: Good Gear Guide
A cikkben emlegetett néhány tény az azóta eltelt fejlesztéseknek köszönhetően ma már nem érvényes a MenuetOS-re.
Fordította: Sipos Róbert
2009. augusztus

Beszélgetés MenuetOS fejlesztőivel. Egy operációs rendszer teljes egészében assembly nyelven írva

Az átlagos PC felhasználó azt látja, hogy számítógépének operációs rendszere rengeteg lemezterületet elpazarol. A Windows Vista Premium 15 GB lemezterületet igényel és komoly követelményeket támaszt mind az asztali mind a hordozható számítógépekkel szemben. Kétségtelen, hogy részben a Microsoftnak köszönhetően az emberek egy része folyamatos hardvervásárlási lázban él, hogy az operációs rendszerből a legtöbbet kihozhassa - vagy akár csak használhatóvá tegye. [Ezzel én nem illetve csak részben értek egyet. A hardvervásárlási lázat ma már az átlagos felhasználóban sokkal inkább a játékok okozzák. - A ford.] A MenuetOS fejlesztői egy másfajta hozzáállással rendelkeznek: operációs rendszerük könnyed és hihetetlenül gyors annak ellenére, hogy rengeteg olyan díszt tartalmaz, amit elvárunk ma egy modern operációs rendszertől. A rendszer preemptív multitaszkingot biztosít, csinos, modern GUI-t, TCP/IP meghajtót az Internet eléréshez, stb. És persze nem utolsó sorban lehet rajta futtatni a Quake-et. Ami pedig még meglepőbb, hogy az egész rendszer elfér egy floppy lemezen. Mindezek mögött a titok nem meglepő módon a fejlesztési folyamat.

kep1 A modern operációs rendszerek túlnyomórészt magas szintű nyelven készülnek (C és C++). A Menuet viszont teljes egészében assembly-ben íródott: a gépi nyelv szimbolikus reprezentációjában. Napjainkban a programozóknak minimális kapcsolatuk van a gépi kóddal (ha van egyáltalán), de ez nem ijesztette el a Menuet fejlesztőit! Az eredmény egy egyszerű, kicsi és szupergyors operációs rendszer. Két fejlesztőt kértek fel, hogy beszéljenek a PC World Australia-nak arról, mi ihlette őket, hogy nekikezdjenek ennek a rendkívüli feladatnak: hogy operációs rendszert írjanak. Emellett kérdezték őket a rendszer jelenlegi állapotáról és a jövőbeli terveikről.

Először is mi ihlette a MeuetOS fejlesztését? A legtöbb ember egy teljes operációs rendszer assembly nyelven írását eléggé vakmerő feladatnak tartaná.

Ville: Az eredeti ötlet néhány évvel ezelőtt jött, amikor interneteztem és találtam egy oldalt, ami egy szkriptnyelvet használt. Még az én relatíve új gépemen is a rövid szkript elég lassan futott le. Úgy tűnt, mitha valami folyamatos kényszer lenne arra, hogy olyan nyelveket hozzanak létre, amelyek egy új CPU-ból az utolsó csepp erőt is kiszívják. Eldöntöttem, hogy a másik végletbe esem és assembly-t használok amennyire csak lehetséges.

Tudsz adni valami áttekintést a fő fejlesztők hátteréről? Vannak, akik a fő csapaton kívülről is hozzájárultak a rendszerhez?

kep2 Madis: Az én szenvedélyem mindig az assembly nyelv volt. Tizenévesként programozható számológépekkel kezdtem, ahol az ML (gép nyelv) volt az egyetlen járható út. Már ehhez képest az assembly is felfrissülést ad és emellett ez egy rendkívül elegáns programozási mód.

Ville: Különböző országokból jöttünk különböző háttérrel, de a legtöbb fejlesztőnknek egyetemi képzettsége van. Én már sok különböző programozási nyelvet használtam 30 év alatt. A BASIC és a Pascal után jött a C és az assembly. És igen, a fejlesztői csapaton kívülről is hozzájárulnak a projekthez fejlesztésekkel, az MP3 lejátszó egy ilyen hozzájárulásként valósult meg.

Melyik része a MenuetOS-nek, amire a legbüszkébbek vagytok? Van olyan része a rendszernek, amit különösen nagy kihívás volt megvalósítani?

Madis: Nagyon büszke vagyok a GUI miatt, mert a legtöbb hobby rendszer csak a parancssorig jut el, de egy true-color módú, VESA-támogatással rendelkező GUI ezektől jóval továbbmegy és ideális játékokhoz és kis grafikus demókhoz. A 64 bites regiszterek lehetővé tették, hogy csak regisztereket használó egyenes és görberajzoló kódokat írjak és ezeket tartom az én mikro-eredményeimnek, amikre büszke vagyok. "Kihívás megvalósítani?" - válaszoljon erre szerintem Ville.

Ville: A tulajdonképpeni kódolást figyelembe véve én legelégedettebb a preemptív ütemezéssel és az USB támogatással vagyok. És talán elértük, hogy az emberek picit másként godolnak arra, hogy mit lehet megvalósítani gépi kódban és mit nem.

Mi jön ezután? Van tervetek az 1.0 verzióig? Vannak olyan eljövő funkciók, amire különösen büszkék vagytok?

Ville: Új meghajtóprogramokat kell írni és fejleszteni kell a jelenlegi alkalmazásokat. Ezen kívül van egy-két teljesen új feladat is, amit szeretnék megvalósítani még az 1.0 mérföldkő előtt.

A Menuet 32 bites verziója a GPL licensz alatt került kiadásra, de a 64 bites változat nem nyílt forrású licenszt használ, viszont engedélyezi az ingyenes felhasználást személyes és oktatási célokra. Miért döntöttetek amellett, hogy a 64 bites verzió más licencelést kap? Volt ez bármien bátorító hatással arra, hogy emberek csatlakozzanak a projekthez?

Ville: Egy teljesen új típusú nyílt forrású projektben az embereknek általában határozott elképzeléseik vannak arról, hogy a fejlesztés milyen irányban haladjon. Ez odáig tud fajulni, hogy vitatkozással már több idő elmegy, mint a tulajdonképpeni kódolással. Amikor ez megtörtént, eldöntöttem, hogy jobban fogok a Menuet eredeti elképzelésére koncentrálni a 64 bites változat esetében egy új licenszszel. Persze semmi ellenvetésem sincs a nyílt forrás ellen vagy az ellen, hogy a Menuet64 forrását később esetleg megnyissuk. De úgy vélem, a jelenlegi licenszszel az emberek talán kicsit elkötelezettebbek lesznek és több erőforrást adnak majd az új tulajdonságok fejlesztésébe.

Használják a Menuet bármely verzióját éles környezetben? Ezt az egészet hobby/oktatási célnak szánod vagy egy olyan rendszer az elképzelésed, ami egy speciális feladatra alkalmas lesz a gazdaságban? Van célközönsége a Menuetnek vagy ez az egész a fejlesztésről szól?

kep3 Madis: A legfontosabb a rendszerrrel kapcsolatban a kis méret, hiszen még mindig elfér egy floppy-n. A megfelelő környezet talán valami beágyazott rendszer lehet. Ami pedig nagyon fontos az, hogy x86-alapú, tehát portolható a legtöbb kompatibilis eszközre. Különösen most, hogy a Mac is Intel CPU-t használ és a későbbi Larrabee chipek szintén az x86 ISA (utasításkéslet) egy részét fogják használni.

Ville: A Menuetet olyan környezetekben használják, ahol tényleges valós idejű vezérlésre van szükség más eszközök fölött. Jelenleg a Menuet főként olyan hobbifelhasználók körőben használatos, akik érdeklődnek az assembly nyelv iránt. Az assembly környezet különben elég kellemes. Vannak új, érdekes megtanulandó szolgáltatások és ami legfontosabb, sosem tudhatod, hogy az emberek milyen felhasználási területtel állnak elő. A csapat jelenlegi célja, hogy kijöjjünk az 1.0-s verzióval.

Gondoljátok, hogy még mindig van az assembler nyelvnek szerepe a MenuetOS-en kívül is? A legtöbb számítógéptudományi tanulmány manapság leginkább a magas szintű nyelvekre koncentrál, mint a Java és a C++ és a legtöbb munkahelyen olyan embereket várnak, akik ilyen nyelvekben jártasak (vagy más magas szintű nyelvekben, mint a PHP és a Visual Basic).

Madis: Azért vannak a kódolási feladatoknak olyan részei, ahol az AMS még mindig szükséges. Persze kevés az olyan eset, ahol az egész programot ebben kell megírni, de az optimizálás manapság egyre fontosabb és azt hiszem, az assembler szerepe pont ebben van. A magas szintű nyelvek tökéletesek a gyors fejlesztéshez, ahol a sebesség nem annyira kritikus.

Ville: Aztán néhány kutatást az anyagi problémák is nyomasztanak. Az oktatásnak pártatlannak és gyártófüggetlennek kellene lennie. Az assembly nyelvek viszont teljes mértékben gyártófüggőek. De maga az assembly kódolás a Menuet magas színvonalú rendszerhívásaival tulajdonképpen elég gyors és könnyen megtanulható.

Milyen fejlesztői eszközökre van a legnagyobb szükségetek, amikor a MenuetOS-en dolgoztok?

Madis: Először is a Flat Assembler (FASM) a legfontosabb, ami a MenuetOS számára generálja a kódot. A FASM makrózási lehetőségei segítik a képekkel és nyers bináris adatokkal való munkát. A hexa-szerkesztő szintén értékes eszköz, ahogy az OS-debugger is, hogy könnyen lehessen tesztelni és módosítani futás közben.

Van valami oka, hogy a FASM-et választottátok?

Ville: FASM az első szolgáltatásgazdag assembler, amit 32 bites x86-ra írtak tisztán assembly-ben. A FASM előtt egy C-ben írt assemblert használtunk. De ma már a FASM a Windowson, Linuxon keresztül a Macintosh-ig több platformot is támogat.

Miért monolitikus a kernel?

Ville: Amikor a folyamatvégrehajtást sokkal tüzetesebben megvizsgálod, láthatod, hogy a Menuet kernelje mind a mikrokerneles mind a monolitikus ütemezési technikából tanult valamit. Az alkalmazások grafikus elérése monolitikus stílusban van implementálva, a hálózatkezelés viszont a mikrokernelekéhez hasonló módon. A monolitikus kernel megbízható alap minden egyéb funkciónak.

kep4 Miért valós idejű az operációs rendszer? Ez elég szokatlan GUI-val párosítva.

Ville: A Menuet taszkkapcsolása egyfajta kombinációja a preemptív és az eseményvezérelt ütemezésnek. Minden processznek van maximális végrehajtási időkerete, amit az időzítő ütemező szakít meg. Beépített GUI-val ennek nincs hátránya, mivel a számítások mennyisége nem igazán változik, ha a multitaszking valós idejű vagy bármi más. Úgyhogy ez inkább a GUI tervezés miatt van, nem pedig az ütemezés típusa miatt.

Egy operációs rendszer írásának az egyik fő problémája a meghajtótámogatás. Hogyan választottátok ki az eszközöket, amiket támogattok?

Ville: Általában megpróbáljuk először a legnépszerűbb eszközöket támogatni. Például támogatjuk az USB video-t, tárolóeszköz és nyomtató osztályokat, amik a legszélesebb körű támogtást biztosítják. De ennél még több meghajtóprogramra van szükség, mielőtt elérjük az 1.0-s mérföldkövet. Jelenleg nekünk csak minimális készlet meghajtóprogramunk van például ahhoz, hogy hálózati alkalmazásokat fejlesszünk.

A Menuet mennyire jól kezeli az egyre inkább terjedő többprocesszoros rendszereket?

Madis: A MenuetOS még mindig csak egy magot használ egy többprocesszoros rendszerben is. Teszteljük annak lehetőségét, hogy kihasználjuk a több magot és több szálat, de ez sok munkát igényel a kernellel, mielőtt kijelenthetjük, hogy működőképes.

Menüetnek van 3-as szintű privilégium támogatása. Pontosan mi fut a hármasban? Csak alkalmazások?

Ville: Csak alkalmazások. A kernel és a meghajtóprogramok a 0-s privilégiumszinten futnak.

Hogyan lehet debugolni, amikor a Menueten dolgoztok?

Madis: Az én kedvencem a QEMU, ami a MenuetOS-t egész jól futtatja. Egy alkalmazáshoz egyébként számos megközelítés lehetséges. Az egyik az IPC, amikor egy másik program figyel a debug-sztringekre vagy az elküldött értékekre. Egy másik lehetőség, hogy felfüggesztjük a program végrehajtását (jmp $) a kérdéses pontban és a QEMU használatával megvizsgáljuk a regiszterek és a memória állapotát abban a helyzetben.

Ville: Én személy szerint szeretem egyszerűsíteni a kódot, amikor egy bonyolult helyzettel találkozom. Biztosnak kell lennünk, hogy a kód funkcionalitása mennyire jó, nem számít mennyire intelligensek az eszközeink.

kep5 Úgy tűnik, van brk (64-es rendszerhívás), de nincs malloc? Ez nem kitolás kicsit, különösen hogy milyen jó magas szintű rendszerhívásaitok vannak? Hogy működik általában a memóriafoglalás?

Ville: Jelenleg a Menuet alkalmazásoknak folyamatos memóriatartományuk van, amit rendszerhívással lehet átméretezni. A program binárisa a terület elején helyezkedik el, a többi hely pedig felhasználható az adatoknak. Ez jelentősen egyszerűsíti mindenféle szemétgyűjtő feladatát, amikor az alkalmazás kilép. Az OS-nek csak az alkalmazás által használt eszközöket kell felszabadítania. A malloc különben nincs a todo listánkon.

Van munka a C könyvtárak Menuet-re portolásán is. Jelenleg ez hol áll?

Ville: A C könyvtár a GPL licence alapján jelent meg és főként 32 bites kódként fordítottuk le. A Menuet64 teljes mértékben képes futtatni a 32 bites könyvtárakat és alkalmazásokat. Jelenleg van Quake, Doom, Dosbox és egyéb C-alapú alkalmazásaink, amik mind a Menuet32-n mind a Menuet64-en futnak.

Látni fogunk valaha POSIX támogatást?

Ville: A POSIX kétségkívül erőteljes megoldás. De a Menuetben a rendszerhívásokat megpróbáljuk relatíve magas szinten tartani, mint például a create_window és putimage, ami assembly-ben egyszerűsíti és gyorsítja az alkalmazásfejlesztést.