| MINIX 3 | |
|---|---|
| X11 - skal med TWM - vinduehåndtering , der kører på MINIX 3-operativsystemet | |
| Udvikler | Andrew Tanenbaum |
| OS familie | UNIX-lignende operativsystem |
| nyeste version | |
| Hyppighed af opdatering af endelige versioner | Ja |
| Understøttede platforme | i386 ( IA-32 ) |
| Kernel type | mikrokerne |
| Licens | BSD |
| Stat | Faktiske |
| Kildekodelager | git.minix3.org/?p=minix.… |
| Tidligere | Minix |
| Internet side | minix3.org |
MINIX 3 er et projekt, der skal skabe et lille , meget pålideligt og funktionelt Unix-lignende operativsystem . Det blev udgivet under BSD-licensen og er efterfølgeren til de tidligere oprettede MINIX 1 og MINIX 2 operativsystemer .
Hovedmålet med projektet er at skabe et fejltolerant system, der er i stand til at opdage og rette sine egne fejl "on the fly" uden direkte brugerindblanding. Grundlæggende var det meningen, at det skulle bruge operativsystemet i indlejrede systemer og uddannelse. [3]
MINIX 3 understøtter i øjeblikket IA-32- arkitekturen for pc-kompatible computere . Det er også muligt at køre MINIX under emulatorer og virtuelle maskiner som Bochs , [4] [5] VMware Workstation , [6] Microsoft Virtual PC [7] og QEMU . Porte til ARM [8] og PowerPC [9] arkitekturer er under udvikling.
Det distribueres som et operativsystembillede indlæst fra flytbare medier ( Live CD ).
I betragtning af karakteren af systemer baseret på en monolitisk kerne , hvor en driver (som ifølge skaberen af MINIX 3 Tanenbaum indeholder omkring 3-7 gange flere fejl end et normalt program) [10] kan crashe hele systemet, [11 ] MINIX 3 sigter mod at skabe et operativsystem, der ville være "en pålidelig, selvhelbredende, multi-server UNIX- klon ." [12]
For at opnå dette skal kode, der kører i kernetilstand, holdes på et minimum, og filserveren, processerveren og hver enhedsdriver skal køre som separate processer i brugertilstand. Hver driver styres omhyggeligt af en del af systemet kendt som gendannelsesserveren. Hvis driveren ikke reagerer på ping fra gendannelsesserveren, lukkes den og erstattes med en ny kopi.
På et monolitisk system kan en fejl i en driver crashe hele kernen, hvilket er meget mindre sandsynligt i MINIX 3. [13]
MINIX 3 blev annonceret den 24. oktober 2005 af Andrew Tanenbaum under hans åbningsforedrag på ACM Operating Systems Principles Symposium . Mens MINIX 3 stadig fungerer som planen for den nye udgave af Tanenbaum og Woodhulls bog, er den blevet omdesignet til at være "brugelig som et robust operativsystem til indlejrede og ressourcebegrænsede enheder, der kræver høj pålidelighed."
| version | udgivelses dato | Beskrivelse |
|---|---|---|
| 3.1.0 | 2005-10-24 |
|
| 3.1.2a | 2006-05-29 |
|
| 3.1.3 | 2007-04-13 |
|
| 3.1.3a | 2007-06-08 |
|
| 3.1.4 | 2009-06-09 |
|
| 3.1.5 | 2009-11-05 |
|
| 3.1.6 | 2010-02-08 |
|
| 3.1.7 | 2010-06-16 |
|
| 3.1.8 | 2010-10-04 | |
| 3.2.0 | 2012-02-29 |
|
| 3.2.1 | 2013-02-21 |
|
| 3.3.0 | 2014-09-16 |
|
| ||
Med udgivelsen af MINIX 3.2.0 er den officielle hjemmeside blevet forbedret. Dens fordel er, at download-knappen og links til andre vigtige sider er placeret direkte på hovedsiden. Den officielle wiki har endnu ikke modtaget den nødvendige revision og er i øjeblikket drevet af MoinMoin .
Hovedmålet med MINIX 3 er pålidelighed. Nedenfor er nogle af de vigtigste principper for at forbedre pålideligheden.
Monolitiske operativsystemer som Linux og FreeBSD og en hybrid som Windows indeholder millioner af linjer kernekode . MINIX 3 har omkring 6.000 linjer eksekverbar kernekode, hvilket gør det nemmere at spore et problem i koden.
I et monolitisk OS findes enhedsdrivere i kernen. Dette betyder, at når en ny perifer enhed indlæses, injiceres ukendt og potentielt ikke-pålidelig kode i kernen. En fejl i førerkoden kan føre til ødelæggelse af systemet. I MINIX 3 kører hver driver i sin egen proces. Drivere kan ikke udføre privilegerede kommandoer såsom ændring af sidetabeller , vilkårlig I/O eller skrivning til hukommelsen på en absolut adresse. De er tvunget til at foretage opkald til kernen for at gøre det, og den vil kontrollere hver kommando for gyldighed.
I et monolitisk operativsystem kan føreren skrive et hvilket som helst ord til hukommelsen og dermed ved et uheld ødelægge brugerprogrammet. I MINIX 3, når en bruger forventer data fra f.eks. et filsystem, opretter den et håndtag, der angiver, hvem der har adgang til hvilke adresser. Det sender derefter indekset for den deskriptor til filsystemet, som derefter kan videregive det til driveren. Filsystemet eller driveren anmoder kernen om at skrive til denne deskriptor, hvilket gør det umuligt for dem at skrive adresser uden for bufferen.
Hvis der henvises til en dårlig pointer i en driver, ville det dræbe driverprocessen, men ville ikke have nogen effekt på systemet som helhed. Reinkarnationsserveren genstarter automatisk den styrtede driver. For nogle drivere (såsom disk- og netværksdrivere) er gendannelse gennemsigtig for brugerprocesser, mens for andre (såsom lyd- og printerdrivere) kan brugeren blive underrettet. I monolitiske systemer ødelægger systemet systemet, hvis der henvises til en dårlig pointer i kernen eller driveren.
Hvis driveren kommer ind i en uendelig løkke , vil planlæggeren gradvist sænke sin prioritet, indtil den går i standbytilstand. Til sidst vil reinkarnationsserveren se, at driveren ikke reagerer på statusanmodninger, så den dræber og starter driveren i en løkke. På et monolitisk system kan sløjfe af driveren få systemet til at hænge.
MINIX 3 bruger en fast beskedlængde til intern kommunikation, hvilket eliminerer visse problemer med overløb og bufferhåndtering. Mange udnyttelser fungerer også ved at overfylde en buffer for at narre et program til at vende tilbage fra en opkaldsfunktion og overskrive returadressen, der peger på den overfyldte buffer ved hjælp af stakken. I MINIX 3 vil dette angreb ikke virke, fordi kommandoen og dataene er adskilt af mellemrum, og kun koden (koden, der skal læses) til kommandoen kan udføres.
Enhedsdrivere får adgang til kernefunktioner (såsom kopiering af data fra brugeradresserum) gennem opkald til kernen. I Minix 3 har kernen en bitmap, der fortæller hver driver, hvilke opkald den må foretage. I monolitiske systemer kan hver driver kalde enhver kernefunktion, uanset om den er autoriseret eller ej.
Kernen vedligeholder også en tabel, der fortæller hver driver, hvilke I/O-porte den har adgang til. Som følge heraf kan driveren kun arbejde med sine egne I/O-porte. På monolitiske systemer kan driveren få adgang til I/O-porte, der tilhører andre enheder.
Ikke alle drivere eller servere behøver at kommunikere med andre sådanne drivere eller servere. Derfor bestemmer bitmapprocessen, hvilke retninger hver proces kan få adgang til.
En speciel enhed kaldet reinkarnationsserveren poller hver chauffør med jævne mellemrum. Hvis driveren stopper eller undlader at reagere på anmodninger, erstatter reinkarnationsserveren den automatisk med en ny kopi. Registrering og udskiftning af ikke-funktionelle drivere sker automatisk uden brugerindblanding. Denne funktion virker ikke for diskdrivere i øjeblikket, men i den næste version vil systemet være i stand til at gendanne alle diskdrivere, der er skjult i RAM . Gendannelse af driveren vil ikke påvirke arbejdsgangen.
Når der opstår en afbrydelse, oversættes det til en meddelelse sendt til den relevante driver. Hvis chaufføren venter på en besked, så modtager den afbrydelsen med det samme, ellers får den besked næste gang. Dette skema eliminerer indlejrede afbrydelser og gør det lettere at skrive en driver.
Som du kan se, er det nederste niveau mikrokernen , som består af omkring 4000 linjer kode (for det meste i C og en lille mængde i assemblersprog ). Den håndterer afbrydelser , udfører planlægning og videregivelse af beskeder. Den understøtter også en API på omkring 30 kernekald, som en tjeneste eller driver kan foretage. Brugerprogrammet kan ikke foretage sådanne opkald. I stedet kan de foretage POSIX -systemopkald, der sender beskeder til tjenester. Kernekaldet udfører funktioner såsom konfiguration af interrupts og kopiering af data mellem adresserum.
På næste niveau er enhedsdrivere , som hver kører som en separat brugerproces. Hver af dem styrer visse I/O-enheder, såsom en disk eller en printer. Driveren har ikke adgang til I/O-porte og kan ikke udstede direkte instruktioner. I stedet skal de foretage et systemkald med en liste over I/O-porte og værdier at skrive til. Denne ordning, mens den introducerer en lille overhead (ca. 500 nanosekunder), tillader kernen at kontrollere tilladelser, så f.eks. lyddriveren ikke kan skrive data til disken.
Det næste niveau er serveren. Næsten al funktionaliteten af OS er placeret der. Brugerprocesser arbejder med filer, for eksempel ved at sende en besked til en filserver for at åbne, lukke, læse og skrive filer. Til gengæld modtager filserveren I/O for at sende en besked til diskdriveren, som faktisk administrerer disken.
En af nøgleserverne er reinkarnationsserveren. Dens opgave er at polle alle servere og drivere for med jævne mellemrum at kontrollere deres helbred. Hvis komponenterne ikke reagerer korrekt, så falder de ind i en endeløs løkke, reinkarnationsserveren (som er den overordnede proces for drivere og servere) ødelægger den fejlslagne komponent og erstatter den med en ny kopi. I dette tilfælde bliver systemet automatisk selvhelbredende uden indblanding af kørende programmer.
I øjeblikket er reinkarnationsserveren, filserveren, processerveren og mikrokernen en del af den betroede computerbase. Hvis nogen af dem "falder", så fejler hele systemet. At reducere beregningsgrundlaget fra 3-5 millioner linjer kode på Linux eller 20.000 linjer Windows forbedrer systemets pålidelighed betydeligt.
MINIX 1, 1.5 og 2 blev skabt som værktøjer til undervisning i OS-design.
MINIX 1.0 blev skabt i 1987. De 12.000 linjer med kernekildekode blev primært skrevet i programmeringssproget C og assemblersproget. Kernekildekoden, filsystemet og hukommelsesstyringssystemet blev trykt i bogen. Tanenbaum skabte oprindeligt MINIX til IBM PC og IBM PC/AT computere , der var tilgængelige på det tidspunkt.
MINIX 1.5, udgivet i 1991, inkluderede understøttelse af IBM PS/2 MicroChannel og blev også overført til Motorola 68000 og SPARC arkitekturerne , der understøttede Atari ST , Commodore Amiga , Apple Macintosh og Sun Microsystems SPARCstation computerplatforme. En MINIX-version er også tilgængelig, der kører som en brugerproces under SunOS .
MINIX 2, udgivet i 1997, var kun tilgængelig til x86- og SPARC-arkitekturerne . Minix-vmd blev skabt af to forskere ved Vrije Universiteit med tilføjet virtuel hukommelse og understøttelse af X Window System .
MINIX 3 gør det samme og giver et moderne styresystem med mange nye værktøjer og Unix-applikationer. [15] Professor Tanenbaum sagde engang:
Husk på, at MINIX 3 ikke er din bedstefars MINIX... MINIX 1 blev skrevet som en tutorial... MINIX 3 er begyndelsen på et yderst pålideligt, selvhelbredende, oppustet OS... MINIX 1 og MINIX 3 er relaterede på samme måde som Windows 3.1 og Windows XP er - den samme del af navnet. [12]
MINIX 3.2.0 blev udgivet i februar 2012. Denne version har mange nye funktioner, inklusive Clang-kompileren , eksperimentel symmetrisk multiprocessor-understøttelse, procfs og ext2fs -filunderstøttelse og GDB . Flere dele af NetBSD var også inkluderet i udgivelsen, inklusive bootloaderen, libc og forskellige andre biblioteker. [16]
MINIX 3.2.1 blev udgivet den 21. februar 2013.
| Realtids operativsystemer | |
|---|---|
| |
| åben | |
| Proprietære |
|
| historisk |
|
| |