Mach | |
---|---|
Type | mikrokerne |
Forfatter | Carnegie Mellon University (CMU) |
Skrevet i | C og assemblersprog |
Første udgave | 1985 [1] |
nyeste version | 3.0 |
Internet side | cs.cmu.edu/afs/cs/projec… |
Mach er en mikrokerne af operativsystemet udviklet på Carnegie Mellon University under forskningsarbejde inden for operativsystemer, primært distribueret og parallel computing. Dette er et af de allerførste eksempler på en mikrokerne, men det er stadig standarden for andre lignende projekter.
Projektet eksisterede fra 1985 til 1994 og sluttede med udgivelsen af Mach 3.0. Flere forskningsgrupper fortsatte udviklingen af Mach; for eksempel kørte University of Utah Mach 4-projektet [2] i nogen tid . Mach blev designet som en erstatning for BSD UNIX-kernen, så der var ingen grund til at udvikle et nyt driftsmiljø. Yderligere forskningsarbejde om Mach-projektet ser ud til at være afsluttet; trods dette bruges Mach og dets derivater i en række kommercielle operativsystemer, såsom NeXTSTEP , hvoraf det mest bemærkelsesværdige er Mac OS X , som bruger XNU-kernen , der inkorporerer Mach 2.5. Machs virtuelle hukommelsesstyringssystem blev overtaget af BSD-udviklerne i CSRG og bruges i moderne BSD-afledte UNIX-systemer såsom FreeBSD. Hverken Mac OS X eller FreeBSD bibeholdt mikrokernearkitekturen brugt af Mach, selvom Mac OS X tilbyder mikrokerne interproceskommunikation og kontrolprimitiver til brug i applikationer.
Mach er en logisk forlængelse af Accent -kernen , også udviklet på Carnegie Mellon University . Siden 1991 har den ledende udvikler af projektet, Richard Rashid, arbejdet hos Microsoft i Microsoft Research-divisionen. En anden af hovedudviklerne, Avetis Tevanyan , arbejdede som chef for softwareudvikling hos NeXT , derefter, indtil marts 2006, chef for avancerede softwareteknologier hos Apple .
Da Mach blev designet som en hurtig erstatning for den traditionelle Unix -kerne , vil vi fokusere på forskellene mellem Mach og Unix . Det er blevet klart, at "alt er en fil" Unix-konceptet ikke længere fungerer på moderne systemer, men systemer som Plan 9 fra Bell Labs forsøger stadig at følge denne vej. Mach-udviklerne bemærkede ufleksibiliteten i denne tilgang og foreslog, at endnu et lag af virtualisering kunne få systemet til at "arbejde" igen.
En af de vigtigste abstraktioner i Unix er rør . Hvad ligner rørledninger og vil gøre det muligt på et mere generelt plan at gøre de forskellige bevægelser af information mellem programmer tilgængelige? Et sådant system kan eksistere ved hjælp af inter-process communication (IPC), et pipeline-lignende princip til at organisere kommunikation mellem processer, der gør det muligt at flytte enhver fillignende information mellem to programmer. Mens forskellige implementeringer af IPC har eksisteret på mange systemer, inklusive forskellige Unix'er, i flere år, blev de designet til specielle formål og kunne ikke levere, hvad skaberne af Mach forventede af dem.
Carnegie Mellon University begyndte at udvikle Accent-kernen ved hjælp af delt hukommelse baseret IPC . Accent var et eksperimentelt system med en masse funktioner, udviklet efter modetrends gennem hele udviklingen. Derudover var Accents anvendelighed til forskning begrænset, fordi den ikke var Unix-kompatibel, og Unix var allerede de facto-standarden på alle forskningsoperativsystemer. Derudover var Accent tæt knyttet til platformen, som den blev udviklet på. Men i begyndelsen af 1980'erne så det ud til, at mange nye platforme snart ville dukke op, hvoraf mange ville understøtte massiv parallelisme.
I begyndelsen blev udviklingen af Mach hovedsageligt set som et forsøg på at skabe en konceptuelt "ren", Unix-baseret, let bærbar Accent. Følgende hovedbegreber blev formuleret:
Mach er baseret på koncepterne fra IPC Accent, men gjort mere som et Unix-system, der giver dig mulighed for at køre Unix-programmer med ringe eller ingen ændringer. For at nå dette mål introducerede Mach konceptet med en "havn", der repræsenterer slutningen i en tovejs IPC. Porte var sikret og havde filtilladelser svarende til Unix-filtilladelser og brugte en meget lignende sikkerhedsmodel som Unix . Derudover tillod Mach ethvert program at eje privilegier, der normalt kun er reserveret til kernen, hvilket tillader et uprivilegeret niveau (brugerplads) at få adgang til hardwaren.
I Mach, som i Unix , er OS igen primært blevet et sæt hjælpeprogrammer. Ligesom Unix har Mach konceptet med en "driver" som mellemled mellem selve kernen og hardwaren. Alle drivere til eksisterende hardware skal dog inkluderes i mikrokernen. Andre arkitekturer baseret på hardwareabstraktionslag eller exokerneler kan adskille drivere fra mikrokernen.
Den største forskel fra Unix var, at hjælpeprogrammerne ikke skulle arbejde med filer, men med opgaver. Mere kode er blevet flyttet ud af kernen og over i ikke-privilegeret tilstand. Grundet dette er kernen blevet væsentligt mindre, deraf betegnelsen mikrokerne for Mach kernen. I modsætning til traditionelle systemer kan en proces (eller "opgave") under Mach bestå af et sæt tråde. Mach var det første operativsystem, der definerede "tråd" i denne forstand. Kernens opgaver blev reduceret til at arbejde med hardware og understøttende hjælpeprogrammer.
Eksistensen af porte og brugen af IPC definerer de fleste af forskellene mellem Mach og traditionelle kerner. I Unix bruges " systemkald " eller " signaler " til at få adgang til kernen . Programmet bruger biblioteket til at placere dataene på et kendt sted i hukommelsen og laver derefter en speciel softwareafbrydelse . Når systemet først starter kernen, sætter det en interrupt-handler op , så det program, der kaster interruptet , kalder kernen, som undersøger den indkommende information og skrider til handling.
Mach bruger IPC til dette formål. Programmet beder kernen om adgang til porten og bruger derefter IPC-mekanismen til at sende beskeder til porten. I andre kerner håndteres disse meddelelser af systemkald; i Mach håndteres næsten alle anmodninger af et andet program.
Brugen af IPC til meddelelsesoverførsel understøtter tråde og påstande. Fordi opgaver er sammensat af flere tråde, og deres trådede kode bruger IPC-mekanismen, kan Mach fryse eller ophæve en tråd, mens en meddelelse behandles. Dette gør det muligt for systemet at blive distribueret på tværs af flere processorer ved at bruge delt hukommelse direkte i de fleste Mach-meddelelser, eller ved at tilføje kode for at kopiere meddelelsen til en anden processor, hvis det kræves. I en traditionel kerne er dette svært at implementere, fordi systemet skal være sikker på, at forskellige programmer ikke forsøger at skrive til den samme hukommelse på forskellige processorer. I Mach er dette veldefineret og nemt at implementere; en proces, der får adgang til hukommelse, porte, bliver en "borger" i systemet.
IPC-systemet har præstationsproblemer, som der er udviklet flere strategier til at overvinde. Især bruger Mach en enkelt hukommelsesdelingsmekanisme til fysisk at sende beskeder fra et program til et andet. Fysisk kopiering af beskeden vil være langsom, så Mach ser til hukommelsesstyringsenheden (MMU) for hurtigt at kortlægge data fra et program til et andet. Kun hvis data er skrevet, vil det blive fysisk kopieret, en proces kaldet " kopier -på-skriv" (kopi-på-skriv; ko).
Meddelelser kontrolleres også for integritet af kernen for at undgå dårlige data, der vil ødelægge et af de programmer, der udgør systemet. Porte blev udviklet baseret på Unix-filsystemet. Dette gjorde det muligt for porte at bruge de eksisterende koncepter for filsystemnavigation samt tilladelser.
Sammenlignet med mere traditionelle operativsystemer bliver udviklingen af et sådant system lettere. Det meste af systemet kan startes, fejlsøges og bygges ved hjælp af de samme hjælpeprogrammer som programmer til et traditionelt system. Med en monolitisk kerne kræver en fejl i koden, at man lukker hele maskinen ned og genstarter, mens det i Mach kun kræver en genstart af programmet. Derudover kan brugeren bede systemet om at aktivere eller deaktivere funktioner som ønsket. Da OS er en samling af programmer, kan udviklere tilføje eller fjerne dele af det ved blot at starte eller stoppe dem som ethvert andet program.
Mach var oprindeligt placeret som tilføjelseskode skrevet til den eksisterende 4.2BSD-kerne, der tillod kommandoen at køre på systemet længe før den var færdig. Arbejdet startede med et færdiglavet Accent IPC /port system og flyttede til andre nøgledele af OS, opgaver, tråde og virtuel hukommelse. Disse dele er blevet omskrevet til at kalde funktioner i Mach; sideløbende hermed blev der arbejdet med 4.3BSD.
I 1986 blev systemet færdigt og kunne køre på en DEC VAX . Selvom det var af ringe praktisk betydning, blev målet om at skabe en mikrokerne bragt til live. Versioner til IBM PC/RT- og Sun Microsystems 68030 - arbejdsstationerne fulgte snart efter , hvilket gav systemportabilitet. I 1987 inkluderede listen Encore Multimax og Sequent Balance . Udgivelse 1 udkom i år, og udgivelse 2 næste.
Hele denne tid blev den lovede "rigtige" mikrokerne ikke skabt. Disse tidlige versioner af Mach inkluderede det meste af 4.3BSD-kernen, et system kendt som POE , med det resultat, at kernen faktisk var større end den Unix, den var baseret på. Målet om at flytte Unix-laget ud af kernen, hvor det lettere kunne udvikles og erstattes, blev dog nået. Ydeevnen lod meget tilbage at ønske, og der blev foretaget en række arkitektoniske ændringer for at løse dette problem.
Som et resultat kom Mach 3 ud i 1990 og skabte stor interesse. Det lille team, der lavede Mach, porterede det til en række forskellige platforme, inklusive komplekse multiprocessorsystemer, der udgjorde alvorlige problemer for gammeldags kerner. Interessen blev også aktiveret i det kommercielle segment af markedet, hvor der var virksomheder, der gerne ville kunne skifte platform, og hvis de porterede deres OS til Mach, kunne de skifte platform smertefrit.
Mach fik et synligt løft, da Open Source Foundation annoncerede, at de ville bygge en fremtidig version af OSF/1 på Mach 2.5, og gerne ville bruge Mach 3. Mach 2.5 blev også valgt til NeXTSTEP- systemer og en række kommercielle multiprocessorer producenter. Med Mach 3 har der været en række forsøg på at portere andre operativsystemer til denne kerne, inklusive IBM Workplace OS og adskillige forsøg fra Apple Computer på at skabe en version af Mac OS på tværs af platforme .
I et stykke tid så det ud til, at hvert operativsystem bygget i slutningen af 1990'erne ville være baseret på Mach.
Mach var oprindeligt placeret som en erstatning for klassisk Unix, og indeholder derfor mange Unix-ideer. For eksempel bruger Mach et rettigheder og sikkerhedssystem baseret på Unix-filsystemet. Da kernen kører i privilegeret tilstand (kerne-mode), og det er muligt, at nogle programmer vil sende en kommando, der vil beskadige systemet, skal kernen tjekke hver besked. Desuden var det meste af funktionaliteten placeret i programmer, der kørte i ikke-privilegeret tilstand (brugerplads), hvilket betyder, at der er behov for en eller anden måde for at tillade sådanne programmer yderligere handlinger, såsom at arbejde med hardware.
Nogle Mach-funktioner var baseret på de samme IPC-mekanismer. For eksempel kan Mach nemt understøtte multiprocessor-computere. I den traditionelle kerne arbejdes der omfattende for at sikre, at programmer, der kører på forskellige processorer og kan kalde kernefunktioner på samme tid , er reentrant eller diskontinuerlige. I Mach er dele af operativsystemet isoleret i servere, der kan køre ligesom andre programmer – på enhver processor. Så i teorien burde Mach-kernen også være genindtræden, men i praksis er dette ikke et problem, da alt hvad Mach skal gøre er at dirigere anmodningen til et eller andet uprivilegeret program. Mach inkluderede også en server, der kunne videresende beskeder ikke kun mellem programmer, men på tværs af netværket. Arbejdet på dette område blev udført i slutningen af 1980'erne og begyndelsen af 1990'erne.
Brug af IPC til de fleste opgaver reducerer ydeevnen [3] . Sammenligninger foretaget i 1997 viste, at Unix bygget på Mach 3.0 var 50 % langsommere end traditionel Unix [4] .
Undersøgelser har vist, at ydeevnen falder på grund af IPC, og det er umuligt at opnå acceleration ved at opdele OS i små servere. Der blev gjort mange forsøg på at forbedre Machs præstationer, men i midten af 1990'erne var interessen falmet.
Faktisk har forskning i karakteren af præstationsproblemer afsløret flere interessante fakta: Den ene er, at IPC i sig selv ikke er et problem, problemet er, at hukommelseskortlægning er påkrævet for at understøtte det, hvilket tilføjer lidt overhead. Det meste af tiden (ca. 80%) bruges på yderligere opgaver i kernen - behandling af beskeden, primært kontrol af portrettigheder og beskedintegritet. I test på Intel 80486DX-50 tager et standard Unix-kald omkring 21 mikrosekunder, et tilsvarende opkald i Mach tager 114 mikrosekunder, hvoraf 18 mikrosekunder er relateret til hardware, resten er relateret til forskellige funktioner i Mach-kernen.
Da Mach først blev brugt i seriøs udvikling (version 2.x), var ydeevnen omkring 25 % langsommere end traditionelle kerner. Denne pris var ikke et problem, fordi systemet porterede godt og kørte på flere processorer. Faktisk skjulte systemet alvorlige ydeevneproblemer indtil udgivelsen af Mach 3, hvor mange udviklere forsøgte at skabe systemer, der kører i uprivilegeret tilstand.
Da Mach 3 forsøgte at flytte OS til ikke-privilegeret tilstand, blev ydeevnetabet mærkbart. Lad os overveje et simpelt eksempel: opgaven lærer den aktuelle tid. En besked sendes til Mach-kernen, dette forårsager en kontekstswitch, hukommelseskortlægning, så tjekker kernen beskeden og rettighederne, hvis alt er i orden, kaldes en kontekstswitch til serveren, derefter udfører serveren handlingerne og sender besked tilbage, tildeler kernen mere hukommelse og skifter kontekst to gange.
Men der er et problem her. Det ligger i det virtuelle hukommelsessøgningssystem. Traditionelle monolitiske kerner ved, hvor kernen og dens moduler er, og hvor den hukommelse, der kan bladres ud, er, mens Mach ikke aner, hvad systemet er lavet af. I stedet bruger den en enkelt løsning, der tilføjer ydeevneproblemer. Mach 3 giver en simpel hukommelseshåndtering, der tilgår andre administratorer, der kører i ikke-privilegeret tilstand, hvilket får systemet til at foretage dyre IPC-opkald.
Mange af disse problemer findes i ethvert system, der skal køre på en multiprocessormaskine, og i midten af 1980'erne så det ud til, at det fremtidige marked ville være fyldt med dem. Faktisk fungerer evolutionen ikke som forventet. Multiprocessor-maskiner blev brugt i serverapplikationer i begyndelsen af 1990'erne, men forsvandt derefter. I mellemtiden er CPU-ydeevnen steget med 60 % om året, hvilket multiplicerer kodeineffektiviteten. Det er slemt, at hukommelsesadgangshastigheden kun vokser med 7% om året, hvilket betyder, at omkostningerne ved hukommelsesadgang ikke er faldet, og Machs IPC-opkald, der ikke er cachelagret, er meget langsomme.
På trods af Machs egenskaber er sådanne ydeevnetab i den virkelige verden uacceptable, så meget af OS-udviklingssamfundet mente, at det oprindeligt var en fiasko at bruge IPC som grundlag for OS.
Som vi har nævnt ovenfor, er størstedelen af Mach 3's ydeevne spildt på IPC-opkald. Konceptet med et "multi-server system" er dog stadig lovende, så det kræver forskning. Udviklere skal omhyggeligt isolere kode i moduler, der ikke foretager opkald fra server til server. For eksempel bør det meste netværkskode placeres på en separat server. Under Unix er dette ikke så let, fordi systemet er afhængig af at bruge filsystemet til alt fra netværk til sikkerhed.
De fleste udviklere sidder fast i det originale koncept med en enkelt stor server, der leverer OS-funktionalitet. For at lette udviklingen tillod de også operativsystemet at køre i privilegerede og uprivilegerede tilstande. Dette giver dem mulighed for at udvikle sig i ikke-privilegeret tilstand og have alle funktionerne i Mach-ideen, og derefter flytte den debuggede server til privilegeret tilstand for at få bedre ydeevne. Flere operativsystemer er blevet udviklet på en lignende måde, kendt som "co-location" (co-location), dette bruges i Lites (port 4.4BSD Lite), MkLinux , OSF/1 og NeXTSTEP / OpenStep / Mac OS X. ChorusOS gjorde denne funktion til en del af kernesystemet, hvilket tillod servere at gå ind i privilegeret tilstand ved hjælp af indbyggede mekanismer.
Mach 4 forsøgte at løse dette problem med et radikalt sæt forbedringer. Især fandt han programkode, som normalt ikke er skrevet ned, og derfor sker copy-on-write sjældent. Dette gjorde det muligt ikke at kortlægge hukommelse mellem processer (korthukommelse) for IPC, men i stedet at bruge lokale områder af programhukommelse. Dette skabte konceptet "shuttles" og øget ydeevne, men udviklerne fik kompleksiteten i at administrere stater. Mach 4 inkluderede også indbyggede colocation-mekanismer.
I alle IPC-tests blev ydeevne nævnt som kilden til problemet, der tegner sig for 73 % af tabte cyklusser.
I midten af 90'erne stoppede arbejdet med mikronukleare systemer. Selvom markedet troede, at alle nye systemer ville være mikrokerner i 90'erne, er der i dag kun ét meget brugt Mac OS X-system, der bruger en colocation-server oven på en stærkt modificeret Mach 3-kerne.
Forskning har vist, at IPC-ydelsesproblemet ikke er så slemt, som folk tror. Som en påmindelse tager et envejsopkald på BSD 20 mikrosekunder, mens det på Mach tager 114, hvoraf 11 er en kontekstswitch identisk med BSD. Derudover bruges 18 af hukommelsesadministratoren til at vise en meddelelse mellem den ikke-privilegerede runtime og den privilegerede runtime (bruger-space og kernel-space). Dette tilføjer 31 mikrosekunder, hvilket er længere end et traditionelt opkald, men ikke meget.
Resten af problemet er at kontrollere tilladelserne på meddelelsesporten. Selvom dette ser meget vigtigt ud, er det faktisk kun påkrævet på Unix-systemer. For eksempel har et enkelt brugersystem, der kører på en mobiltelefon, muligvis ikke brug for disse funktioner, og det er den type system, hvor Mach kan bruges. Men Mach skaber problemer: Når hukommelsen flyttes til OS, har andre opgaver muligvis ikke brug for det. DOS og tidlige Mac OS havde et enkelt adresseområde, der blev delt af alle processer, så hukommelseskortlægning er spild af tid på sådanne systemer.
Disse implementeringer indvarslede anden generation af mikrokerner , hvilket reducerer systemets kompleksitet ved at placere det meste af funktionaliteten i ikke-privilegeret eksekveringstilstand. For eksempel indeholder L4 -kernen kun 7 funktioner og bruger 12 kilobyte hukommelse, mens Mach 3 indeholder omkring 140 funktioner og bruger 330 kilobyte hukommelse. Et IPC-kald til L4 på 486DX-50 tager kun 5 mikrosekunder - hurtigere end et Unix-opkald på samme system og 20 gange hurtigere end Mach. Dette tager selvfølgelig ikke højde for det faktum, at L4 ikke opererer på tilladelser og sikkerhed, hvilket overlader dem til uprivilegerede programmer.
De "potentielle" L4 speedups er baseret på det faktum, at ikke-privilegerede applikationer ofte giver mange funktioner, som formelt understøttes af kernen. Du kan sammenligne ydeevnen af MkLinux i colocation-tilstand og en L4-port, der kører i ikke-privilegeret tilstand. L4 tilføjer kun omkring 5-10% overhead, mens Mach tilføjer 15%, hvilket er ret interessant i betragtning af de dobbelte kontekstskift.
Som et resultat har de nye mikrokerner ændret branchen som helhed, hvor mange engang døde projekter som GNU Hurd igen har fået opmærksomhed.
Mach og Mach-lignende operativsystemer | |
---|---|