MINIX 3

MINIX 3  är ett projekt för att skapa ett litet , mycket tillförlitligt och funktionellt Unix-liknande operativsystem . Det publicerades under BSD-licensen och är efterföljaren till de tidigare skapade operativsystemen MINIX 1 och MINIX 2 .

Huvudmålet med projektet är att skapa ett feltolerant system som kan upptäcka och korrigera sina egna fel "i farten" utan direkt användaringripande. I grund och botten var det meningen att det skulle använda operativsystemet i inbyggda system och utbildning. [3]

MINIX 3 stöder för närvarande IA-32- arkitekturen för PC-kompatibla datorer . Det är också möjligt att köra MINIX under emulatorer och virtuella maskiner som Bochs , [4] [5] VMware Workstation , [6] Microsoft Virtual PC [7] och QEMU . Portar för ARM [8] och PowerPC [9] arkitekturer är under utveckling.

Den distribueras som en operativsystemavbildning laddad från flyttbara media ( Live CD ).

Projektmål

Med tanke på karaktären hos system baserade på en monolitisk kärna , där en drivrutin (som innehåller, enligt skaparen av MINIX 3 Tanenbaum , cirka 3-7 gånger fler buggar än ett vanligt program) [10] kan krascha hela systemet, [11 ] MINIX 3 syftar till att skapa ett operativsystem som skulle vara "en pålitlig, självläkande UNIX- klon med flera servrar ." [12]

För att uppnå detta bör kod som körs i kärnläge hållas till ett minimum, och filservern, processservern och varje enhetsdrivrutin bör köras som separata processer i användarläge. Varje drivrutin kontrolleras noggrant av en del av systemet som kallas återställningsservern. Om drivrutinen inte svarar på ping från återställningsservern stängs den och ersätts med en ny kopia.

På ett monolitiskt system kan en bugg i en drivrutin krascha hela kärnan, vilket är mycket mindre troligt i MINIX 3. [13]

Historik

MINIX 3 tillkännagavs den 24 oktober 2005 av Andrew Tanenbaum under hans öppningstal vid ACM Operating Systems Principles Symposium . Medan MINIX 3 fortfarande fungerar som ritningen för den nya upplagan av Tanenbaum och Woodhulls bok, har den designats om för att vara "användbart som ett robust operativsystem för inbäddade och resursbegränsade enheter som kräver hög tillförlitlighet."

Webbplatsrevision

Med lanseringen av MINIX 3.2.0 har den officiella webbplatsen förbättrats. Dess fördel är att nedladdningsknappen och länkar till andra viktiga sidor placeras direkt på huvudsidan. Den officiella wikin har ännu inte fått den nödvändiga revideringen och drivs för närvarande av MoinMoin .

Tillförlitligheten hos MINIX 3

Huvudmålet med MINIX 3 är tillförlitlighet. Nedan finns några av de viktigaste principerna för att förbättra tillförlitligheten.

Minska storleken på kärnan

Monolitiska operativsystem som Linux och FreeBSD , och en hybrid som Windows , innehåller miljontals rader kärnkod . MINIX 3 har cirka 6 000 rader körbar kärnkod, vilket gör det lättare att spåra ett problem i koden.

Urklippsfel

I ett monolitiskt operativsystem finns drivrutiner i kärnan. Detta innebär att när en ny kringutrustning laddas in, injiceras okänd och potentiellt opålitlig kod i kärnan. Ett fel i förarkoden kan leda till att systemet förstörs. I MINIX 3 kör varje förare i sin egen process. Drivrutiner kan inte utföra privilegierade kommandon som att ändra sidtabeller , godtycklig I/O eller skriva till minnet på en absolut adress. De tvingas göra anrop till kärnan för att göra det, och den kommer att kontrollera varje kommando för giltighet.

Begränsa förarens åtkomst till minnet

I ett monolitiskt operativsystem kan föraren skriva vilket ord som helst till minnet och därmed av misstag skada användarprogrammet. I MINIX 3, när en användare förväntar sig data från till exempel ett filsystem, skapar den ett handtag som indikerar vem som har tillgång till vilka adresser. Den skickar sedan indexet för den deskriptorn till filsystemet, som sedan kan skicka det till drivrutinen. Filsystemet eller drivrutinen begär att kärnan ska skriva till denna deskriptor, vilket gör det omöjligt för dem att skriva adresser utanför bufferten.

Att hålla defekta pekare vid liv

Att avhänvisa en dålig pekare i en drivrutin skulle döda förarprocessen, men skulle inte ha någon effekt på systemet som helhet. Reinkarnationsservern kommer automatiskt att starta om den kraschade drivrutinen. För vissa drivrutiner (som disk- och nätverksdrivrutiner) är återställning transparent för användarprocesser, medan för andra (som ljud- och skrivardrivrutiner) kan användaren meddelas. I monolitiska system bryts systemet av att referera till en dålig pekare i kärnan eller drivrutinen.

Manuella oändliga loopar

Om föraren hamnar i en oändlig loop kommer schemaläggaren gradvis att sänka sin prioritet tills den går i standbyläge. Så småningom kommer reinkarnationsservern att se att föraren inte svarar på statusförfrågningar, så den kommer att döda och starta föraren i en loop. På ett monolitiskt system kan en looping av drivrutinen göra att systemet hänger sig.

Skadebegränsning för buffertspill

MINIX 3 använder en fast meddelandelängd för intern kommunikation, vilket eliminerar vissa överflödes- och bufferthanteringsproblem. Många utnyttjar fungerar också genom att en buffert flödar över för att lura ett program att återvända från en anropsfunktion och skriva över returadressen som pekar på den överfyllda bufferten med hjälp av stacken. I MINIX 3 kommer denna attack inte att fungera eftersom kommandot och data är åtskilda av mellanslag och endast koden (koden som ska läsas) för kommandot kan köras.

Begränsa åtkomst till kärnfunktioner

Enhetsdrivrutiner får åtkomst till kärnfunktioner (som att kopiera data från användarens adressutrymme) genom anrop till kärnan. I Minix 3 har kärnan en bitmapp som talar om för varje drivrutin vilka anrop den får göra. I monolitiska system kan varje drivrutin anropa vilken kärnfunktion som helst, oavsett om den är auktoriserad eller inte.

Begränsa åtkomst till I/O-portar

Kärnan har också en tabell som talar om för varje drivrutin vilka I/O-portar den har tillgång till. Som ett resultat kan drivrutinen bara arbeta med sina egna I/O-portar. På monolitiska system kan föraren komma åt I/O-portar som tillhör andra enheter.

Begränsa kommunikation med OS-komponenter

Alla drivrutiner eller servrar behöver inte kommunicera med andra sådana drivrutiner eller servrar. Följaktligen bestämmer bitmappsprocessen vilka riktningar varje process kan komma åt.

Återställa stoppade eller problematiska drivrutiner

En speciell enhet som kallas reinkarnationsservern undersöker varje förare regelbundet. Om föraren stannar eller inte svarar på förfrågningar, ersätter reinkarnationsservern den automatiskt med en ny kopia. Detektering och ersättning av icke-funktionella drivrutiner sker automatiskt utan någon inblandning från användaren. Den här funktionen fungerar inte för diskdrivrutiner för närvarande, men i nästa version kommer systemet att kunna återställa alla diskdrivrutiner som är gömda i RAM . Att återställa drivrutinen påverkar inte arbetsflödet.

Inbyggda avbrott och meddelanden

När ett avbrott inträffar översätts det till ett meddelande som skickas till lämplig förare. Om föraren väntar på ett meddelande får den avbrottet omedelbart, annars kommer det att meddelas nästa gång. Detta schema eliminerar kapslade avbrott och gör det lättare att skriva en drivrutin.

Arkitektur

Som du kan se är bottennivån mikrokärnan , som består av cirka 4000 rader kod (mest i C och en liten mängd i assemblerspråk ). Den hanterar avbrott , schemalägger och skickar meddelanden. Den stöder också ett API med cirka 30 kärnanrop som en tjänst eller drivrutin kan göra. Användarprogrammet kan inte göra sådana samtal. Istället kan de göra POSIX -systemsamtal som skickar meddelanden till tjänster. Kärnanropet utför funktioner som att konfigurera avbrott och kopiera data mellan adressutrymmen.

På nästa nivå finns enhetsdrivrutiner , var och en körs som en separat användarprocess. Var och en av dem styr vissa I/O-enheter, till exempel en disk eller en skrivare. Drivrutinen har inte tillgång till I/O-portar och kan inte ge direkta instruktioner. Istället måste de göra ett systemanrop med en lista över I/O-portar och värden att skriva till. Detta schema, samtidigt som det introducerar en liten overhead (cirka 500 nanosekunder), tillåter kärnan att kontrollera behörigheter så att till exempel ljuddrivrutinen inte kan skriva data till disken.

Nästa nivå är servern. Nästan all funktionalitet i operativsystemet finns där. Användarprocesser fungerar med filer, till exempel genom att skicka ett meddelande till en filserver för att öppna, stänga, läsa och skriva filer. I sin tur tar filservern emot I/O för att skicka ett meddelande till diskdrivrutinen, som faktiskt hanterar disken.

En av nyckelservrarna är reinkarnationsservern. Dess uppgift är att kontrollera alla servrar och drivrutiner för att regelbundet kontrollera deras hälsa. Om komponenterna inte svarar korrekt, då hamnar de i en oändlig loop, reinkarnationsservern (som är den överordnade processen för drivrutiner och servrar) förstör den misslyckade komponenten och ersätter den med en ny kopia. I det här fallet blir systemet automatiskt självläkande utan inblandning av pågående program.

För närvarande är reinkarnationsservern, filservern, processservern och mikrokärnan en del av den betrodda datorbasen. Om någon av dem "faller" så misslyckas hela systemet. Men att minska beräkningsbasen från 3-5 miljoner rader kod på Linux eller 20 000 rader Windows förbättrar systemets tillförlitlighet avsevärt.

Skillnader mellan MINIX 3 och tidigare versioner

MINIX 1, 1.5 och 2 skapades som verktyg för att lära ut OS-design.

MINIX 1.0 skapades 1987. De 12 000 raderna med kärnkällkod skrevs huvudsakligen i programmeringsspråket C och assemblerspråket. Kärnans källkod, filsystem och minneshanteringssystem trycktes i boken. Tanenbaum skapade ursprungligen MINIX för IBM PC och IBM PC/AT -datorer som var tillgängliga vid den tiden.

MINIX 1.5, som släpptes 1991, inkluderade stöd för IBM PS/2 MicroChannel och portades även till Motorola 68000 och SPARC-arkitekturerna som stöder datorplattformarna Atari ST , Commodore Amiga , Apple Macintosh och Sun Microsystems SPARCstation . En MINIX-version finns också tillgänglig som körs som en användarprocess under SunOS .

MINIX 2, som släpptes 1997, var endast tillgänglig för arkitekturerna x86 och SPARC . Minix-vmd skapades av två forskare vid Vrije Universiteit , med extra virtuellt minne och stöd för X Window System .

MINIX 3 gör detsamma och ger ett modernt operativsystem med många nya verktyg och Unix-applikationer. [15] Professor Tanenbaum sa en gång:

Tänk på att MINIX 3 inte är din farfars MINIX... MINIX 1 skrevs som en handledning... MINIX 3 är början på ett mycket tillförlitligt, självläkande, svullnadsfritt OS... MINIX 1 och MINIX 3 är relaterade på samma sätt som Windows 3.1 och Windows XP är - samma del av namnet. [12]

MINIX 3.2.0 släpptes i februari 2012. Den här versionen har många nya funktioner, inklusive Clang-kompilatorn , experimentellt symmetriskt multiprocessorstöd, procfs och ext2fs filstöd och GDB . Flera delar av NetBSD inkluderades också i utgåvan, inklusive bootloader, libc och olika andra bibliotek. [16]

MINIX 3.2.1 släpptes den 21 februari 2013.

Litteratur

• Tanenbaum, Andrew S; Albert S. Woodhull. Operativsystem: Design och  implementering . — 3:a. - Prentice Hall , 2006. - ISBN 0-13-142938-8 .
• Bygga ett pålitligt operativsystem: feltolerans i MINIX 3 av Jorrit N. Herder
• Reorganizing UNIX for Reliability av Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg och Andrew S. Tanenbaum.
• Modulär systemprogrammering i MINIX 3 av Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg och Andrew S Tanenbaum
• JN Herder et al., Modular System Programming i MINIX 3, ;Login, april 2006 [9]
• Pablo A Pessolani. MINIX4RT: Ett realtidsoperativsystem baserat på MINIX [10]
• Bygga prestandamätningsverktyg för operativsystemet MINIX 3, av Rogier Meurs [11]
• Design och implementering av det virtuella filsystemet MINIX [12]
• Referensmanual för MINIX 3 Kernel API [13]  (nedlänk sedan 2013-05-14 [3461 dagar] - historik )
• Mot ett riktigt mikrokärnoperativsystem [14]
• Konstruktion av ett mycket pålitligt operativsystem [15]
• Minix 3 och mikrokärnupplevelsen: Smart Kernel av Rudiger Weis

Anteckningar

1. ↑ (ospecificerad titel) - 2014.
2. ↑ http://www.minix3.org/330.html
3. ↑ "LWN.net." LWN: MINIX 3 träffar nätet. 28 okt 2005. Eklektix , Inc. 4 jul 2006 [1] Arkiverad 14 juli 2015 på Wayback Machine .
4. ↑ Woodhull, Al. Komma igång med Minix på Bochs på Mac OS. 20 feb 2003. 8 juli 2006 [2] Arkiverad 7 oktober 2013 på Wayback Machine .
5. ↑ Senn, Will. OSNews.com. Virtually Minix: A Tutorial & Intro to Minix on XP via Bochs - OSNews.com. 8 juli 2006. OSNews.com. 8 juli 2006 [3] Arkiverad 10 december 2006 på Wayback Machine .
6. ↑ Wagström, Patrick. Minix under VMWare Installation How-To. 8 jul 2006 Arkiverad kopia (länk ej tillgänglig) . Hämtad 1 maj 2014. Arkiverad från originalet 12 november 2013.  (obestämd)  .
7. ↑ Woodhull, Al. Minix på virtuell PC: första titt. 2 juni 2005. 8 juli 2006 . Datum för åtkomst: 10 december 2012. Arkiverad från originalet den 7 oktober 2013. (obestämd)
8. ↑ MINIX 3 Operativsystems officiella webbplats . Hämtad 10 december 2012. Arkiverad från originalet 21 juni 2012. (obestämd)
9. ↑ Alting, Ingmar A. MinixPPC: En port av MINIX 3 till PowerPC-plattformen, 15 september 2006. [4] Arkiverad 6 februari 2012 på Wayback Machine
10. ↑ Tanenbaum, Andy Introduktion till MINIX 3 . OSnew . OSnews (25 september 2006). - "Från Rebirth- sektionen: "Olika studier har visat att mjukvara i stort sett innehåller ungefär 6-16 buggar per 1000 rader kod och att drivrutiner har 3-7 gånger så många buggar som resten av operativsystemet. I kombination med faktum att 70 % av ett typiskt operativsystem består av enhetsdrivrutiner , det är tydligt att enhetsdrivrutiner är en stor källa till problem. , något måste göras för att hantera buggiga enhetsdrivrutiner. Bygga ett pålitligt system trots de oundvikliga buggarna i enheten drivers var den ursprungliga drivkraften bakom MINIX 3."". Hämtad 4 juli 2008. Arkiverad från originalet 18 januari 2013. (obestämd)
11. ↑ Tanenbaum, Andrew. CSAIL-evenemangskalender. 25 augusti 2006 [5] Arkiverad 4 februari 2012 på Wayback Machine .
12. ↑ 1 2 Tanenbaum, Andrew. "Tanenbaum-Torvalds debatt, del II:." 12 maj 2006. Vrije Universiteit. 15 juni 2006 [6] Arkiverad 5 augusti 2015 på Wayback Machine .
13. ↑ Tanenbaum, Andrew S. "Tillförlitlighet." Operativsystemet MINIX 3. Vrije universitet. 22 juni 2006 [7] Arkiverad 1 juli 2006.  (otillgänglig länk sedan 2013-05-14 [3461 dagar] - historik )
14. ↑ Individuell programmeringsuppgift Schemaläggning av användarläge i MINIX 3 Arkiverad 8 maj 2016 på Wayback Machine av Bjorn Patrick Swift
15. ↑ Woodhull, Albert S.. "MINIX 3: Ett litet, pålitligt gratis operativsystem: "MINIX 3 FAQ. 24 okt 2005. Vrije Universiteit. 15 juni 2006 [8] Arkiverad 30 augusti 2015 på Wayback Machine .
16. ↑ MINIX Releases . wiki.minix3.org . Datum för åtkomst: 29 februari 2012. Arkiverad från originalet den 18 januari 2013. (obestämd)

Länkar

• http://www.minix3.org/
• http://www.minix3.ru/
• http://www.osnews.com/story/15960/Introduction-to-MINIX-3