Metoder för att implementera applikationsprogramvarumiljöer. Programvara Sätt att implementera tillämpningsprogram
Läs också
Medan många OS-arkitektoniska funktioner är direkt relaterade till systemprogrammerare, är konceptet med flera applikationer (operativa) anläggningar direkt relaterat till slutanvändarnas behov - förmågan att operativ system köra applikationer skrivna för andra operativsystem. Denna egenskap hos operativsystemet kallas kompatibilitet.
Applikationskompatibilitet kan vara på binär nivå och på källnivå [ 13 ]. Applikationer lagras vanligtvis i operativsystemet som körbara filer som innehåller binära bilder av kod och data. Binär kompatibilitet uppnås när du kan ta ett körbart program och köra det på en annan OS-miljö.
Kompatibilitet på källnivå kräver närvaron av en lämplig kompilator i programvaran på den dator som den är avsedd att köras på den här applikationen, samt kompatibilitet på nivån för bibliotek och systemanrop. Detta kräver omkompilering av applikationens källkod till en ny körbar modul.
Kompatibilitet på källnivå är viktig främst för applikationsutvecklare som har dessa källor till sitt förfogande. Men för slutanvändare är endast binär kompatibilitet av praktisk betydelse, eftersom de endast i detta fall kan använda samma produkt på olika operativsystem och på olika maskiner.
Typen av möjlig kompatibilitet beror på många faktorer. Den viktigaste av dem är processorns arkitektur. Om processorn använder samma instruktionsuppsättning (kanske med tillägg, som i fallet med IBM PC: standarduppsättning + multimedia + grafik + streaming) och samma adressintervall, kan binär kompatibilitet uppnås helt enkelt. För detta måste följande villkor vara uppfyllda:
API:et som applikationen använder måste stödjas av det givna operativsystemet;
den interna strukturen för programmets körbara fil måste matcha strukturen för operativsystemets körbara filer.
Om processorerna har olika arkitekturer, är det, förutom ovanstående villkor, nödvändigt att organisera emulering av den binära koden. Till exempel, emulering av Intel-processorinstruktioner på Motorola 680x0-processorn på Macintosh används ofta. Programvaruemulatorn väljer i det här fallet den binära instruktionen sekventiellt Intel-processor och exekverar motsvarande subrutin skriven i Motorolas processorinstruktioner. Eftersom Motorola-processorn inte har exakt samma register, flaggor, intern ALU, etc., som i Intel-processorer, måste den också simulera (emulera) alla dessa element med hjälp av sina egna register eller minne.
Det är enkelt men väldigt långsamt arbete, eftersom en Intel-instruktion exekveras mycket snabbare än sekvensen av instruktioner från Motorola-processorn som emulerar den. Utvägen i sådana fall är användningen av så kallade programvarumiljöer eller operativa miljöer. En av komponenterna i en sådan miljö är en uppsättning applikationsgränssnittsfunktioner. API-programmering, som operativsystemet tillhandahåller till sina applikationer. För att minska tiden för exekvering av andras program, imiterar applikationsmiljöer anrop till biblioteksfunktioner.
Effektiviteten av detta tillvägagångssätt beror på det faktum att de flesta av dagens program körs under kontroll av GUI (grafiska användargränssnitt) Windows typ, MAC eller UNIX-motiv, med applikationer som spenderar 60-80 % av sin tid på att göra GUI-funktioner och andra OS-biblioteksanrop. Det är den här egenskapen hos applikationer som gör att applikationsmiljöer kan kompensera för den långa tiden som läggs på kommando-för-kommando-emulering av program. En noggrant utformad mjukvarumiljö inkluderar bibliotek som efterliknar GUI-bibliotek, men skrivna i "native" kod. Således uppnås en betydande acceleration av exekveringen av program med API:et för ett annat operativsystem. Annars kallas detta tillvägagångssätt översättning - för att särskilja det från den långsammare processen att emulera en instruktion i taget.
Till exempel för ett Windows-program som körs på en Macintosh, vid tolkning av processorkommandon Intel prestanda kan vara mycket låg. Men när en GUI-funktion anropas öppnas ett fönster, etc., OS-modulen som implementerar applikationen Windows-miljö, kan avlyssna detta samtal och omdirigera det till en omkompilerad för Motorola 680x0-processorn för att öppna ett fönster. Som ett resultat, i sådana avsnitt av koden, kan programmets hastighet nå (och möjligen överträffa) arbetshastigheten på sin egen processor.
För att ett program som är skrivet för ett operativsystem ska köras på ett annat operativsystem, räcker det inte bara för att säkerställa API-kompatibilitet. Begreppen som ligger bakom olika operativsystem kan komma i konflikt med varandra. Till exempel, i ett operativsystem kan en applikation tillåtas att styra I/O-enheter, i ett annat är dessa åtgärder operativsystemets privilegium.
Varje operativsystem har sina egna resursskyddsmekanismer, sina egna fel- och undantagshanteringsalgoritmer, speciell processorstruktur och minneshanteringsschema, sin egen filåtkomstsemantik och grafik användargränssnitt. För att säkerställa kompatibilitet är det nödvändigt att organisera en konfliktfri samexistens inom samma OS av flera sätt att hantera datorresurser.
Det finns olika alternativ för att bygga flera applikationsmiljöer, som skiljer sig både i egenskaper hos arkitektoniska lösningar och i funktionalitet som ger varierande grad av applikationsportabilitet. Ett av de mest uppenbara alternativen för att implementera flera applikationsmiljöer är baserat på operativsystemets standardlagerstruktur.
På ris. 1.9 OS1 stöder, förutom sina "native" applikationer, applikationer för operativsystemen OS2 och OS3. För detta innehåller den speciella tillämpningar, applikationsprogrammeringsmiljöer som översätter gränssnitten för "främmande" operativsystem API OS2 och API OS3 till gränssnittet för deras "inhemska" OS - API OS1. Så, till exempel, om OS2 var UNIX OS och OS1 var OS/2, för att exekvera systemanropet fork()-processskapande i en UNIX-applikation, måste mjukvarumiljön komma åt OS/2-operativsystemkärnan med systemet genom att anropa DOS ExecPgm().
Ris. 1.9. Organisering av flera applikationsmiljöer
Tyvärr skiljer sig beteendet hos nästan alla funktioner som utgör API:et för ett operativsystem som regel avsevärt från beteendet hos motsvarande funktioner i ett annat operativsystem. Till exempel, för att funktionen för att skapa processer i OS/2 Dos ExecPgm() ska vara helt överensstämmande med funktionen för att skapa processer fork() i UNIX-liknande system, skulle den behöva ändras och ny funktionalitet skrivas: stöd för förmåga att kopiera adressutrymmet för den överordnade processen till utrymmet för den underordnade processen [ 17 ].
Ett annat sätt att bygga flera applikationsmiljöer är baserat på mikrokärnmetoden. Samtidigt är det mycket viktigt att notera den grundläggande, gemensamma för alla applikationsmiljöer, skillnaden mellan operativsystemets mekanismer och de högnivåfunktioner som är specifika för var och en av applikationsmiljöerna som löser strategiska problem. I enlighet med mikrokärnarkitekturen implementeras alla OS-funktioner av mikrokärnan och användarlägesservrarna. Det är viktigt att applikationsmiljön är utformad i formuläret separat server användarläge och inkluderar inte de underliggande mekanismerna.
Applikationer, med hjälp av API:et, gör systemanrop till motsvarande applikationsmiljö genom mikrokärnan. Applikationsmiljön bearbetar begäran, exekverar den (kanske genom att be om hjälp från mikrokärnans grundläggande funktioner för detta), och skickar resultatet tillbaka till applikationen. Under utförandet av begäran måste applikationsmiljön i sin tur komma åt de underliggande OS-mekanismerna som implementeras av mikrokärnan och andra OS-servrar.
Denna metod för att designa flera applikationsmiljöer har alla fördelar och nackdelar med mikrokärnarkitektur, i synnerhet:
det är mycket enkelt att lägga till och utesluta applikationsmiljöer, vilket är en konsekvens av den goda utökbarheten hos mikrokärnoperativsystem;
om en av applikationsmiljöerna misslyckas förblir resten i drift, vilket bidrar till systemets tillförlitlighet och stabilitet som helhet;
låg prestanda hos mikrokärnoperativsystem påverkar applikationsverktygens hastighet och därmed applikationernas hastighet.
Som ett resultat bör det noteras att skapandet inom samma OS av flera applikationsverktyg för att köra applikationer av olika OS är ett sätt som låter dig ha en enda version av programmet och överföra det mellan olika operativsystem. Flera applikationsmiljöer säkerställer binär kompatibilitet för ett givet operativsystem med applikationer skrivna för andra operativsystem.
Det räcker att skapa en komplett applikationsmiljö som är helt kompatibel med miljön i ett annat operativsystem utmanande uppgift, nära relaterat till operativsystemets struktur. Det finns olika alternativ för att bygga flera applikationsmiljöer, som skiljer sig både i egenskaperna hos arkitektoniska lösningar och funktionalitet, vilket ger varierande grad av applikationsportabilitet.
I många versioner av UNIX-operativsystemet är applikationsmiljööversättaren implementerad som en vanlig applikation. I operativsystem byggda med hjälp av mikrokärnkonceptet, såsom Windows NT, körs applikationsmiljöer som användarlägesservrar. Och i OS/2, med sin enklare arkitektur, är applikationsmiljöer inbyggda djupt i operativsystemet.
Ett av de mest uppenbara alternativen för att implementera flera applikationsmiljöer är baserat på operativsystemets standardlagerstruktur. På fig. 3. 8 operativsystem OS1 stöder, förutom sina "inhemska" applikationer, applikationer för operativsystemet OS2. För att göra detta inkluderar den en speciell applikation - en applikationsprogrammiljö som översätter gränssnittet för ett "främmande" operativsystem - API OS2 till gränssnittet för dess "inhemska" operativsystem - API OS1.
Ris. 3. 8. Programvarumiljö som sänder
systemsamtal
I en annan implementering av flera applikationsmiljöer har operativsystemet flera peer-applikationsprogrammeringsgränssnitt. I fig. 3. I exemplet stöder operativsystemet applikationer skrivna för OS1, OS2 och OS3. För att göra detta placeras applikationsprogrammeringsgränssnitten för alla dessa operativsystem direkt i systemets kärna: API OS1, API OS2 och API OS3.
Ris. 3. 9. Implementering av kompatibilitet baserat på flera
peer API:er
I denna variant anropar API-nivåfunktionerna funktionerna för den underliggande OS-nivån, som måste stödja alla tre generellt inkompatibla applikationsmiljöer. Olika operativsystem hanterar systemtiden på olika sätt, använder olika tidsformat, delar upp CPU-tid baserat på sina egna algoritmer, etc. Funktionerna för varje API implementeras av kärnan med hänsyn till specifikationerna för motsvarande OS, även om de har ett liknande syfte.
Ett annat sätt att bygga flera applikationsmiljöer är baserat på mikrokärnmetoden. Samtidigt är det mycket viktigt att separera de grundläggande, gemensamma för alla applikationsmiljöer, mekanismerna i operativsystemet från de högnivåfunktioner som är specifika för var och en av applikationsmiljöerna som löser strategiska problem.
I enlighet med mikrokärnarkitekturen implementeras alla OS-funktioner av mikrokärnan och användarlägesservrarna. Det är viktigt att varje applikationsmiljö är utformad som en separat server i användarläge och inte inkluderar grundläggande mekanismer (Fig. 3. 10). Applikationer som använder API-åtkomst systemsamtal till motsvarande applikationsmiljö genom mikrokärnan. Applikationsmiljön bearbetar begäran, exekverar den (kanske genom att be om hjälp från mikrokärnans grundläggande funktioner för detta), och skickar resultatet tillbaka till applikationen. Under utförandet av begäran måste applikationsmiljön i sin tur komma åt de underliggande OS-mekanismerna som implementeras av mikrokärnan och andra OS-servrar.
Ris. 3. 10. Microkernel tillvägagångssätt för genomförandet av flera
applikationsmiljöer
Denna metod för att designa flera applikationsmiljöer har alla fördelar och nackdelar med en mikrokärnarkitektur, i synnerhet:
Det är mycket enkelt att lägga till och utesluta applikationsmiljöer, vilket är en konsekvens av den goda utökningsbarheten hos mikrokärnoperativsystem;
Tillförlitlighet och stabilitet uttrycks i det faktum att om en av applikationsmiljöerna misslyckas, förblir alla andra i drift;
· Låg prestanda hos mikrokärnoperativsystem påverkar applikationsmiljöernas hastighet och därmed hastigheten på applikationsexekveringen.
Skapandet inom ett operativsystem av flera applikationsmiljöer för exekvering av applikationer av olika operativsystem är ett sätt som låter dig ha en enda version av programmet och överföra det mellan operativsystem. Flera applikationsmiljöer säkerställer binär kompatibilitet för ett givet operativsystem med applikationer skrivna för andra operativsystem. Som ett resultat har användarna större frihet att välja operativsystem och mer lätt tillgång till kvalitetsmjukvara.
Frågor för självrannsakan
- Vad menas med OS-arkitektur?
- Vilka är de tre huvudskikten i ett datorsystems struktur?
- Vilken roll har operativsystemet tilldelat systemanropsgränssnittet?
- Vilka villkor måste uppfyllas när man designar ett OS för att operativsystemet ska vara lätt att bära?
- Vad är skillnaden mellan mikrokärnarkitektur och traditionell OS-arkitektur?
- Varför är mikrokärnan väl lämpad för att stödja distribuerad datoranvändning?
- Vad menas med konceptet med flera applikationsmiljöer?
- Vad är kärnan i biblioteksöversättningsmetoden?
Slut på arbetet -
Detta ämne tillhör:
Operativsystem, processer, hårdvara
Operativsystemet för OS i största utsträckning bestämmer utseendet på hela datorsystemet som helhet, operativsystemet utför två väsentligen lite relaterade .. OS som en virtuell utökad maskin användningen av de flesta datorer .. från användarens synvinkel , OS:s funktion är att förse användaren med någon utökad eller virtuell ..
Om du behöver ytterligare material om detta ämne, eller om du inte hittade det du letade efter, rekommenderar vi att du använder sökningen i vår databas med verk:
Vad ska vi göra med det mottagna materialet:
Om det här materialet visade sig vara användbart för dig kan du spara det på din sida på sociala nätverk:
| tweeta |
Alla ämnen i detta avsnitt:
Funktioner hos hårdvaruplattformar
Operativsystemets egenskaper påverkas direkt av hårdvaran som det är orienterat mot. Operativsystem klassificeras efter typ av hårdvara. personliga datorer, mi
Uppgifter och övningar
1. Vilka händelser i utvecklingen av den tekniska basen för datorer blev milstolpar i operativsystemens historia? 2. Vad var den grundläggande skillnaden mellan de första batchbearbetningsmonitorerna och
Operativsystems arkitektur
Varje välorganiserat komplext system har en tydlig och rationell struktur, det vill säga det är uppdelat i delar - moduler som har ett helt färdigt funktionellt syfte med
Huvudminneshantering
Minne är en stor mängd ord eller bytes, var och en med sin egen adress. Detta är ett datalager som tillhandahålls snabb åtkomst fördelat mellan processorn och
Extern minneshantering
Eftersom huvudminnet (primärminnet) är flyktigt och för litet för att hålla alla data och program permanent, måste VS tillhandahålla sekundärt minne för att spara huvudminnet. Bol
Filhanteringsundersystem
En fil är en samling relaterad information som definieras vid skapandet. Förutom själva data representerar filer program, både i käll- och objektform. Delsystem
Nätverk
Distribuerat system - en uppsättning processorer som inte allokerar minne eller varje processor har sitt eget lokala minne. Processorerna i systemet är anslutna av datornätverk och tillhandahåller
Kernel och extra OS-moduler
Det mest allmänna tillvägagångssättet för struktureringen av operativsystemet är uppdelningen av alla dess moduler i två grupper: kärna - OS-moduler som utför grundläggande funktioner;
Kärna och privilegierat läge
För att på ett tillförlitligt sätt kontrollera exekveringen av applikationer måste operativsystemet ha vissa privilegier över applikationer. Annars kan en felaktigt fungerande applikation
Layered OS-struktur
Ett datorsystem som körs under ett kärnbaserat OS kan ses som ett system som består av tre hierarkiskt arrangerade lager: det nedersta lagret utgör hårdvaran
Kärnstruktur
OS hårdvarustöd. Hittills har operativsystemet talats om som en uppsättning program, men vissa av funktionerna i operativsystemet kan också utföras av hårdvara. Poet
Hårdvaruberoende och OS-portabilitet
Många operativsystem körs framgångsrikt på olika hårdvaruplattformar utan betydande förändringar i deras sammansättning. Detta beror till stor del på att det trots skillnaderna
Operativsystems portabilitet
Om operativsystemskod relativt enkelt kan portas från en typ av processor till en annan typ av processor, och från en typ av hårdvaruplattform till en hårdvaruplattform
Begrepp
Mikrokärnarkitektur är ett alternativ till det klassiska sättet att bygga ett operativsystem. Klassisk arkitektur avser i detta fall den strukturella organisationen som diskuterats ovan.
Binär och källkompatibilitet
Det är nödvändigt att skilja mellan kompatibilitet på binär nivå och kompatibilitet på källkodsnivå. Applikationer lagras vanligtvis i operativsystemet som körbara filer som innehåller binära bilder.
Översättning av bibliotek
Utvägen i sådana fall är att använda den sk applikationsprogram miljöer. En av komponenterna som bildar programvarumiljön är en uppsättning funktioner
Process koncept
En process är en aktivitet som körs på en processor. I vid bemärkelse är en processor vilken enhet som helst i en dator som
Resurs koncept
En av funktionerna hos operativsystemet är att tillhandahålla ett effektivt och konfliktfritt sätt att hantera resurserna i ett datorsystem. En resurs förstås ofta som en indikator
Begreppet virtualisering
Virtualisering av den eller den resursen utförs inom ramen för ett centraliserat resursallokeringsschema. Genom virtualisering implementeras två former av användarbedrägeri:
Discipliner för enkelorderservice
a) FIFO (First In -- First Out) - servicedisciplin i mottagningsordningen. Alla förfrågningar hamnar i slutet av kön. Ansökningarna i spetsen av kön serveras först. Schematisk
Avbryta systemet
En situation som uppstår som ett resultat av påverkan av någon oberoende händelse, vilket leder till ett tillfälligt upphörande av exekveringen av en sekvens av kommandon i ett program med syftet
Process koncept
En process (uppgift) är ett program som är i körningsläge. Varje process har sitt eget adressutrymme kopplat till sig, från vilket det kan läsa och
Processmodell
I ett multitasking-system växlar den verkliga processorn från process till process, men för att förenkla modellen övervägs en uppsättning processer som körs parallellt (pseudo-parallell). Överväga
Att avsluta en process
(call exit eller ExitProcess): Schemalagd uppsägning (slut på körning) Schemalagd avslutning vid ett känt fel (t.ex. saknad fil)
Processhierarki
UNIX-system har en stel processhierarki. Varje ny process som skapas av gaffelsystemanropet är ett barn till den tidigare processen. Barnprocessen får från föräldraprocessen
Processstatus
De tre tillstånden för en process är: Kör (upptar processorn) Klar (processen är tillfälligt avstängd för att tillåta en annan process att köras) Väntar (processen
Begreppet flöde
Varje process har ett adressutrymme och en enda ström av körbara instruktioner. I fleranvändarsystem, med varje samtal till samma tjänst, ankomsten
flödesmodell
Varje tråd är associerad med: Räknare för kommandoexekvering Register för aktuella variabler Stack State Trådar delar element sinsemellan
Fördelar med att använda trådar
Förenkla programmet i vissa fall genom att använda ett gemensamt adressutrymme. Hastigheten för att skapa en tråd, jämfört med en process, är cirka 100 gånger. Befordrad
Implementering av trådar i användarutrymme, kernel och mixed
A - trådar i användarutrymme B
Windows-implementeringsfunktioner
Fyra begrepp används: Job - en uppsättning processer med gemensamma kvoter och gränser Process - en behållare med resurser (minne...), innehåller minst en tråd. Poto
Kommunikation mellan processer
Situationer när processer måste interagera: Överföring av information från en process till en annan Kontroll över processernas aktiviteter (till exempel: när de konkurrerar om
Att överföra information från en process till en annan
Överföringen kan göras på flera sätt: Delat minne Kanaler (pipes) är en pseudo-fil som en process skriver till och en annan läser.
Race skick
Ett racetillstånd är en situation där flera processer läser eller skriver data (till minnet eller en fil) samtidigt. Tänk på ett exempel där två processer försöker
Kritiska områden
En kritisk region är en del av ett program som får åtkomst till delad data. Villkor för att undvika tvist och effektivt arbete processer: Två processer är det inte
Lås variabler
Begreppet låsvariabel introduceras, d.v.s. om värdet på denna variabel är lika med till exempel 1, så är resursen upptagen av en annan process, och den andra processen går in i standby-läge (blockerar) tills
Strikt växling
I denna modell kan processer exekveras strikt i sin tur med hjälp av en variabel.
Processinteraktion primitiver
Begreppet två primitiver introduceras. viloläge är en systembegäran som gör att anropsprocessen blockeras tills den startas av en annan process. wak
semaforer
Semaforer är variabler för att räkna triggersignaler som lagras för framtiden. Två operationer ned och upp föreslogs (analoger av sömn och vaken
Schemaläggning i batchbearbetningssystem
6.2.1 First In Fist Out (FIFO) Processer köas när de anländer. Fördelar:
Cyklisk planering
Den enklaste schemaläggningsalgoritmen och ofta använd. Varje process ges en CPU-tidsdel. När kvantumet slutar överförs processen av schemaläggaren till slutet av
Prioriterad planering
Varje process tilldelas en prioritet och kontrollen överförs till processen med högst prioritet. Prioritet kan vara dynamisk eller statisk. Dynamik
Schemaläggning i realtidssystem
Realtidssystem är indelade i: stela (stränga deadlines för varje uppgift) - rörelsekontroll flexibel (brott mot tidsschemat är inte önskvärt, men acceptabelt) -
Allmän realtidsschemaläggning
En modell används när varje process kämpar för processorn med sin egen uppgift och schema för dess utförande. Planeraren behöver veta: med vilken frekvens varje
Process dödläge
Processlåsning kan uppstå när flera processer konkurrerar om samma resurs. Resurser kan vara sökta och icke-sökta, hårdvara och mjukvara.
Modellera dödlägen
Modellera återvändsgränder med grafer. Konventioner På en sådan modell
Detektering och eliminering av dödläge
Systemet försöker inte förhindra dödläget, utan försöker upptäcka det och lösa det. Detektering av dödläge när det finns en resurs av varje typ
Dynamiskt undvikande av dödläge
På så sätt måste operativsystemet veta om resursbidraget är säkert eller inte. Resursbanor Betrakta en modell av två processer och två resurser
Undvik de fyra villkoren som krävs för dödläge
Förebyggande av ömsesidig uteslutning Du kan minimera antalet processer som konkurrerar om resurser. Till exempel att använda skrivarspooling när t
I/O-hårdvaruprinciper
De två lägre nivåerna av I/O-kontrollsystemet är hårdvara: själva enheterna, som direkt utför operationer, och deras kontroller, som tjänar till att organisera gemensamt arbete enhet
Enhetskontroller
I/O-enheter består vanligtvis av två delar: mekanisk (inte att förstå bokstavligt) - disk, skrivare, monitorelektronik - styrenhet eller
Minnesmappad I/O
Varje styrenhet har flera register som används för att interagera med den centrala processorn. Med hjälp av dessa register styr (läser, skriver, sätter på, etc.) OS och bestämmer
Direkt minnesåtkomst (DMA - Direct Memory Access)
Direkt minnesåtkomst implementeras med hjälp av en DMA-styrenhet. Styrenheten innehåller flera register: minnesadressregister byteräknare
Avbryter
Efter att I/O-enheten har startat växlar processorn till andra uppgifter. För att signalera slutet på processorn till processorn initierar enheten ett avbrott,
I/O-programvaruuppgifter
Huvuduppgifterna som ska lösas programvara I/O: Enhetsoberoende - till exempel behöver ett program som läser data från en fil inte tänka på varför
Programvara I/O
I det här fallet gör CPU allt arbete. Överväg processen att skriva ut strängen ABCDEFGH på detta sätt.
Avbrottsdriven I/O
Om bufferten inte används i det föregående exemplet och skrivaren skriver ut 100 tecken per sekund, tar varje tecken 10 ms, under vilken tid processorn kommer att vara inaktiv i väntan på att utskriften ska vara klar.
Avbryt hanterare
Avbrott bör gömmas så djupt som möjligt i operativsystemets tarmar så att så lite av operativsystemet som möjligt måste hantera dem. Det är bäst att blockera drivrutinen som startade I/O. Algo
Drivrutiner för enheter
Enhetsdrivrutin - krävs för varje enhet. Olika operativsystem kräver olika drivrutiner. Drivrutiner måste vara en del av kärnan (på ett monolitiskt system) för att få åtkomst till register.
Enhetsoberoende I/O-programvara
Enhetsoberoende I/O-programvarufunktioner: enhetligt gränssnitt för drivrutiner, buffringsfelmeddelanden
Generalisering av I/O-nivåer och funktioner
Nivåer och grundläggande funktioner i I/O-systemet Baz
Blockerande, icke-blockerande och asynkrona systemsamtal
Alla systemanrop associerade med implementeringen av I/O-operationer kan delas in i tre grupper enligt sätten att implementera interaktionen mellan processen och I/O-enheten. till den första, till
Buffring och cachning
En buffert förstås vanligtvis som ett minnesområde för att lagra information när data utbyts mellan två enheter, två processer eller en process och en enhet. Byt in
Spooling och fånga enheter
Vi pratade om konceptet spooling i den första föreläsningen av vår kurs, som en mekanism som för första gången gjorde det möjligt att kombinera riktiga I/O-operationer av en uppgift med utförande av en annan uppgift.
Avbrott och felhantering
Om datorsystemet, när det arbetar med en extern enhet, inte använder metoden för att polla sitt tillstånd, utan använder avbrottsmekanismen, då när ett avbrott inträffar, som vi redan har
Frågeplanering
När du använder ett icke-blockerande systemsamtal kan det visa sig att önskad enhet redan upptagen med vissa operationer. I detta fall kan det icke-blockerande samtalet omedelbart
Principer bakom UNIX I/O-styrdelsystemet
1. Detta delsystem är byggt på samma sätt som datahanteringsundersystemet (filsystemet). Användaren får ett enhetligt sätt att komma åt både PU:n och filerna. Under fil i OS
OS minneshantering
4.1. Begreppet organisation och ledning fysiskt minne i operativsystem 4.2. Metoder för ansluten tilldelning av huvudminnet 4.2.1. Ansluten distribueras
Förstå organisation och hantering av fysiskt minne i operativsystem
Organisationen och hanteringen av huvudminnet (primärt, fysiskt, verkligt) i en dator är en av de viktigaste faktorerna som bestämmer konstruktionen av operativsystem. På engelska tekniska
Anslutet minnestilldelning för en enskild användare
Ansluten minnesallokering för en användare, även kallad enkel kontinuerlig allokering, används i datorer som arbetar i batch-enprogramläge under kontroll av det enklaste
Tilldelning av anslutet minne i flerprogramsbehandling
Med flerprogramsbehandling placeras flera uppgifter i datorns minne samtidigt. Tilldelningen av minne mellan jobb kan i detta fall göras på följande sätt:
Strategier för att placera information i minnet
Minnestilldelningsstrategier är utformade för att bestämma var i huvudminnet inkommande program och data ska placeras i en icke-flyttbar minnesallokering.
Grundläggande begrepp för virtuellt minne
Termen virtuellt minne förknippas vanligtvis med förmågan att adressera ett minnesutrymme som är mycket större än den primära (verkliga, fysiska) minneskapaciteten för en viss datormaskin.
Personsökning av virtuellt minne
En rent virtuell personsökningsadress är ett ordnat par (p, d), där p är sidnumret i virtuellt minne, och d är förskjutningen inom p-sidan. Processen kan köras
Segmentorganisation av virtuellt minne
Den virtuella adressen i den segmenterade organisationen av virtuellt minne är ett ordnat par n = (s, d), där s är numret på det virtuella minnessegmentet och d är förskjutningen inom detta segment. Processen kan
Sidsegmentsorganisation av virtuellt minne
Personsökningssystem har fördelarna med båda sätten att implementera virtuellt minne. Segment innehåller vanligtvis ett heltal av sidor, och det är inte nödvändigt att alla sidor
Strategier för hantering av virtuellt minne
Strategier för hantering av virtuellt minne, liksom strategier för fysisk minneshantering, delas in i tre kategorier: push-strategier, placeringsstrategier och pop-strategier.
Push Strategier
Följande strategier används för att styra push: pushing (pumpning) on demand (on demand); trycka (pumpa) med bly (förflytta).
Placeringsstrategier
I system med personsökning av virtuellt minne fattas beslutet om placeringen av nyladdade sidor helt enkelt: ny sida kan placeras i valfri gratis
Push Strategier
I multiprogrammeringssystem är allt primärminne som regel upptaget. I det här fallet måste minneshanteraren bestämma vilken sida eller vilket segment som ska tas bort från den primära
Filnamn
Längden på filnamnet beror på operativsystemet, det kan vara från 8 (MS-DOS) till 255 (Windows, LINUX) tecken. OS:er kan skilja mellan versaler och gemener. Till exempel, WINDOWS och windows för MS-DOS är samma och t
Filstruktur
Tre grundläggande filstrukturer: 1. Byte Sequence - OS bryr sig inte om innehållet i filen, det ser bara byte. Den största fördelen med ett sådant system är flexibiliteten
Filtyper
Huvudtyperna av filer: · Vanliga - innehåller användarinformation. Används på Windows och UNIX. · Kataloger - systemfiler tillhandahålla
Filattribut
Huvudfilattribut: · Säkerhet - vem och hur kan komma åt filen (användare, grupper, läsa/skriva). Används på Windows och UNIX. · Lösenord - lösenord till fa
Filer mappade till minnesadressutrymmet
Ibland är det bekvämt att mappa en fil till minnet (du behöver inte använda I/O-systemanrop för att arbeta med filen), och arbeta med minnet och sedan skriva den modifierade filen till disken. När man använder
Katalogsystem på en nivå
I detta system finns alla filer i en katalog. od
Banans namn
För att organisera ett katalogträd behöver du något sätt att specificera en fil. De två huvudsakliga metoderna för att ange en fil är: absolut sökväg - anger sökvägen från roten
Katalogimplementering
När du öppnar en fil används sökvägsnamnet för att hitta posten i katalogen. Katalogposten pekar på adresserna till diskblock. Beroende på systemet kan detta vara: disk helvete
Implementering av långa filnamn
Tidigare operativsystem använde korta filnamn, MS-DOS upp till 8 tecken, i UNIX version 7 upp till 14 tecken. Nu används längre filnamn (upp till 255 tecken eller mer).
Snabba upp filsökningen
Om katalogen är mycket stor (flera tusen filer) är sekventiell läsning av katalogen inte särskilt effektiv. 1 Använda en hashtabell för att påskynda filsökningar.
A - delad fil
Ett sådant filsystem kallas en riktad acyklisk graf (DAG, Directed Acyclic Graph). Det är ett problem om diskadresserna finns i själva katalogposterna.
Block storlek
Om beslutet fattas att lagra filen i block, så uppstår frågan om storleken på dessa block. Det finns två ytterligheter: Stora block - till exempel 1MB, då tar även en 1 byte fil ett helt block
Redovisning för gratis block
Det finns två huvudsakliga sätt att ta hänsyn till fria block: · En länkad lista med diskblock, varje block innehåller lika många lediga blocknummer som det stör blocket. Ofta för reservlistan
Diskkvoter
För att begränsa användaren finns det en kvotmekanism. Två typer av gränser: Hård - kan inte överskridas Flexibel - kan överskridas, men när användaren loggar ut
Säkerhetskopiering
Fall för vilka säkerhetskopiering är nödvändig: Nödsituationer som resulterar i förlust av data på disken Oavsiktlig radering eller programkorruption av filer
Filsystemkonsistens
Om systemet kraschar innan det modifierade blocket skrivs, kan filsystemet gå in i ett inkonsekvent tillstånd. Speciellt om det är ett i-nodblock, ett katalogblock och
cachelagring
Blockcache (buffertcache) - en uppsättning block lagrade i minnet, men som logiskt hör till disken. Alla läsbegäranden till disken fångas upp, och närvaron av de nödvändiga
ISO 9660 filsystem
Mer information - http://en.wikipedia.org/wiki/ISO_9660 Standarden antogs 1988. Enligt standarden kan diskar delas in i logiska partitioner, men vi kommer att överväga diskar med
ISO 9660 katalogpost
Filplats - numret på det första blocket, eftersom. blocken placeras i sekvens. L - filnamnets längd i byte Filnamn - 8 tecken, 3 tecken i tillägget (på grund av kompatibel
Rock Ridge Extensions för UNIX
Detta tillägg skapades så att UNIX-filsystemet skulle finnas på CD-ROM-skivan. För detta används fältet Systemanvändning. Tillägg innehåller följande fält: 1. PX -
Filsystem UDF (Universal Disk Format)
Mer information - http://ru.wikipedia.org/wiki/Universal_Disk_Format Ursprungligen skapad för DVD, med version 1.50 tillagt stöd för CD-RW och CD-R. Nu senaste versionen
Filsystem MS-DOS (FAT-12,16,32)
De första versionerna hade bara en katalog (MS-DOS 1.0). Sedan MS-DOS 2.0 har en hierarkisk struktur tillämpats. Katalogposter, fast till 32 byte. Filnamn -
De kommer att aktiveras i Windows 98
Arkivattributet behövs för program Reserv exemplar, enligt den bestämmer de om de ska kopiera filen eller inte. Tidsfältet (16 bitar) är uppdelat i tre underfält:
Windows 98-tillägg för FAT-32
10 fria bitar användes för tillägget. Form
Huvudöverbyggnaden över FAT-32, dessa är långa filnamn
Två namn började tilldelas varje fil: 1. Kort 8+3 för kompatibilitet med MS-DOS 2. långt namn fil, i Unicode-format Filen kan nås av alla
Format för postkataloger med ett fragment av ett långt filnamn i Windows 98
Fältet "Attribut" låter dig skilja ett fragment av ett långt namn (värde 0x0F) från en filbeskrivning. Gamla MS-DOS-programkatalogposter med ett attributfältvärde på 0x0
NTFS filsystem
Fil NTFS-system utvecklades för Windows NT. Funktioner: · 64-bitars adresser, dvs. kan teoretiskt stödja 264*216 byte (1 208 925 819 M
Hitta en fil efter namn
När du skapar en fil anropar programmet biblioteksproceduren CreateFile("C:windowsreadmy.txt", ...) Detta anrop går till nivå n delat bibliotek
Filkomprimering
Om filen är markerad som komprimerad komprimeras systemet automatiskt när du skriver och dekomprimerar när du läser. Arbetsalgoritm: 1. De första 16 blocken av filen tas för studier (n
Filkryptering
All information, om den inte är krypterad, kan läsas genom att få tillgång. Därför mest pålitligt skydd information från obehörig åtkomst - kryptering. Även om de stjäl från dig
UNIX V7 filsystem
Även om det är ett gammalt filsystem, används de grundläggande elementen fortfarande av moderna UNIX-system. Funktioner: Filnamn är begränsade till 14 ASCII-tecken, förutom snedstrecket "/&q"
i-nod struktur
Fältbytes Beskrivning Läge Filtyp, säkerhetsbitar, setuid- och setgid-bitar Nlänkar
Skapa och arbeta med en fil
fd=creat("abc", mode) - Ett exempel på att skapa en abc-fil med skyddsläget specificerat i lägesvariabeln (som användare har åtkomst till). Systemet används
BSD filsystem
Grunden är det klassiska UNIX-filsystemet. Funktioner (annorlunda än tidigare system): Ökad filnamnslängd till 255 tecken Omorganiserade kataloger
Plats för EXT2-filsystemet på disken
Andra funktioner: · Blockstorlek 1 KB · Storleken på varje i-nod är 128 byte. i-noden innehåller 12 direkta och 3 indirekta adresser, längden på adressen i i-noden har blivit 4 byte, vilket är ca.
EXT3 filsystem
Till skillnad från EXT2 är EXT3 ett journalfilsystem, d.v.s. kommer inte att hamna i ett inkonsekvent tillstånd efter misslyckanden. Men den är helt kompatibel med EXT2.
XFS filsystem
XFS är ett journalfilsystem utvecklat av Silicon Graphics men nu släppt som öppen källkod. Officiell information på http://oss.sgi.com/projec
RFS filsystem
RFS (RaiserFS) är ett journalfilsystem utvecklat av Namesys. Officiell information om RaiserFS Vissa funktioner: Effektivare arbete
JFS filsystem
JFS (journalförd Filsystem) är ett journalfilsystem utvecklat av IBM för operativsystemet AIX, men nu släppt som öppen källkod. Officiell information om Journaled File S
Struktur för NFS-filsystemnivåer
VFS (Virtual File System) - virtuellt filsystem. Behövs för att hantera tabellen över öppna filer. Inlägg för alla öppna fil kallas v-noder
Emuleringsalternativ - flera applikationsmiljöer, som inkluderar en uppsättning API-funktioner. De imiterar anropet till biblioteksfunktionerna i applikationsmiljön, men i själva verket anropar de sina interna bibliotek. Det kallas biblioteksöversättning. Detta är rent mjukvara.
För att ett program skrivet under ett operativsystem ska fungera under ett annat, är det nödvändigt att säkerställa konfliktfri interaktion mellan processkontrollmetoder i olika operativsystem.
Sätt att implementera programvarumiljöer
Beroende på arkitekturen:
1. Programvarumiljö i form av en applikation (det översta lagret av kärnan i det ursprungliga operativsystemet).
Användarläge, översättning av systemanrop (API-anrop) till inbyggda OS-anrop. Motsvarar klassiska flerskiktsoperativsystem (Unix, Windows).
2. Förekomsten av flera applikationsmiljöer som fungerar lika. Var och en i form av ett separat lager av kärnan.
Privilegerat driftsätt. API anropar funktionerna i det underliggande (privilegierade) lagret i operativsystemet. Uppgiften att känna igen och anpassa samtalet ligger på systemet. Nödvändig Ett stort antal Resurser. En uppsättning identifierande egenskaper skickas till kärnan för igenkänning.
3. Mikronukleär princip.
Alla applikationsmiljöer är utformade som en separat server i användarläge. Applikationer, med hjälp av API:et, gör systemanrop till motsvarande applikationsmiljö genom mikrokärnan. Applikationsmiljön behandlar begäran och returnerar resultatet genom mikrokärnan. Kan använda mikrokärnfunktioner. Flera åtkomst till andra resurser är möjlig (medan mikrokärnan körs).
OS-gränssnitt
OS-gränssnittär ett. Reglerad av standarder (POSIX, ISO).
1. Användargränssnitt- genomförs med hjälp av speciella mjukvarumoduler, som översätter användarförfrågningar på ett speciellt kommandospråk till förfrågningar till operativsystemet.
Uppsättningen av sådana moduler kallas tolk. Den utför lexikalisk och analys och antingen kör kommandot själv eller skickar det till API:t.
2. API- är avsedd att förse applikationsprogram med OS-resurser och implementera andra funktioner. API:t beskriver en uppsättning funktioner, procedurer som hör till kärnan och OS-tillägg. API-användningar systemprogram både inom operativsystemet och utanför det, genom att använda applikationsprogram genom programmeringsmiljön.
Kärnan i att förse OS med resurser är i slutändan ett mjukvaruavbrott. Deras implementering beror på systemet (vektor, tabell). Det finns flera alternativ för att implementera API på OS-nivå (snabbast, lägst), på nivån systemprogrammering(mer abstrakt, mindre snabb) och på nivån med ett externt bibliotek av procedurer och funktioner (liten uppsättning).
Linux OS-gränssnitt:
programvara (utan mellanhänder - det faktiska utförandet av systemanrop);
· kommandorad(mellanhand - ett skal av Shell-tolken som omdirigerar samtalet);
Grafiskt (mellanhänder - Shell + grafiskt skal).
Filsystem är en del av operativsystemet som är utformat för att ge användarna användarvänligt gränssnitt arbeta med filer och säkerställa användningen av filer lagrade på externa media ( HDD+ RAM) av flera användare och processer.
Enligt sammansättningen av FS:
helheten av alla filer på disken på alla media,
uppsättningar av datastrukturer som används för att hantera filer, såsom filkataloger, filbeskrivningar, ledigt och använt diskutrymmesallokeringstabeller,
ett komplex av systemisk mjukvaruverktyg som implementerar filhantering, i synnerhet: skapande, förstörelse, läsning, skrivning, namngivning, sökning och andra operationer på filer.
Ett av attributen för filer är filnamn, ett sätt att identifiera en fil för användaren. I de system där flera namn är tillåtna, tilldelas filen en inod som används av OS-kärnan. Namn i olika operativsystem ställs in olika.
Medan många OS-arkitektoniska funktioner är direkt relaterade till endast systemprogrammerare, är konceptet med flera applikationer (operativa) faciliteter direkt relaterat till slutanvändarnas behov - operativsystemets förmåga att köra applikationer skrivna för andra operativsystem. Denna egenskap hos operativsystemet kallas kompatibilitet.
Programkompatibilitet kan vara på binär nivå och på källkodsnivå. Applikationer lagras vanligtvis i operativsystemet som körbara filer som innehåller binära bilder av kod och data. Binär kompatibilitet uppnås när du kan ta ett körbart program och köra det på en annan OS-miljö.
Kompatibilitet på källnivå kräver att lämplig kompilator ingår i programvaran på den dator som programmet ska köras på, samt kompatibilitet på nivån för bibliotek och systemanrop. Detta kräver omkompilering av applikationens källkod till en ny körbar modul.
Kompatibilitet på källnivå är viktig främst för applikationsutvecklare som har dessa källor till sitt förfogande. Men för slutanvändare är endast binär kompatibilitet av praktisk betydelse, eftersom de endast i detta fall kan använda samma produkt på olika operativsystem och på olika maskiner.
Typen av möjlig kompatibilitet beror på många faktorer. Den viktigaste av dem är processorns arkitektur. Om processorn använder samma instruktionsuppsättning (kanske med tillägg, som i fallet med IBM PC: standarduppsättning + multimedia + grafik + streaming) och samma adressintervall, kan binär kompatibilitet uppnås helt enkelt. För detta måste följande villkor vara uppfyllda:
- API:et som applikationen använder måste stödjas av det givna operativsystemet;
- den interna strukturen för programmets körbara fil måste matcha strukturen för operativsystemets körbara filer.
Om processorerna har olika arkitekturer, är det, förutom ovanstående villkor, nödvändigt att organisera emulering av den binära koden. Till exempel, emulering av Intel-processorinstruktioner på Motorola 680x0-processorn på Macintosh används ofta. Programvaruemulatorn väljer i det här fallet sekventiellt den binära instruktionen för Intel-processorn och exekverar motsvarande subrutin skriven i instruktionerna för Motorola-processorn. Eftersom Motorola-processorn inte har exakt samma register, flaggor, intern ALU, etc., som i Intel-processorer, måste den också simulera (emulera) alla dessa element med hjälp av sina egna register eller minne.
Detta är en enkel men mycket långsam operation, eftersom en enda Intel-instruktion är mycket snabbare än Motorola-instruktionssekvensen som emulerar den. Utvägen i sådana fall är användningen av så kallade programvarumiljöer eller operativa miljöer. En av komponenterna i en sådan miljö är API-uppsättningen funktioner som operativsystemet exponerar för sina applikationer. För att minska tiden för exekvering av andras program, imiterar applikationsmiljöer anrop till biblioteksfunktioner.
Effektiviteten av detta tillvägagångssätt beror på det faktum att de flesta av dagens program körs under GUI (grafiska användargränssnitt) som Windows , MAC eller UNIX Motif , medan applikationer spenderar 60-80 % av tiden med att göra GUI-funktioner och andra OS-biblioteksanrop . Det är den här egenskapen hos applikationer som gör att applikationsmiljöer kan kompensera för den långa tiden som läggs på kommando-för-kommando-emulering av program. En noggrant utformad mjukvarumiljö innehåller bibliotek som efterliknar GUI-bibliotek, men skrivna i inbyggd kod. Således uppnås en betydande acceleration av exekveringen av program med API:et för ett annat operativsystem. Annars kallas detta tillvägagångssätt översättning - för att särskilja det från den långsammare processen att emulera en instruktion i taget.
Till exempel för ett Windows-program som körs på en Macintosh, vid tolkning av kommandon från en Intel-processor prestanda kan vara mycket låg. Men när en GUI-funktion anropas, ett fönster öppnas, etc., kan OS-modulen som implementerar Windows-applikationsmiljön avlyssna detta anrop och omdirigera det till fönsteröppningsrutinen som kompileras om för Motorola 680x0-processorn. Som ett resultat, i sådana avsnitt av koden, kan programmets hastighet nå (och möjligen överträffa) arbetshastigheten på sin egen processor.
För att ett program som är skrivet för ett operativsystem ska köras på ett annat operativsystem räcker det inte bara för att säkerställa API-kompatibilitet. Begreppen som ligger bakom olika operativsystem kan komma i konflikt med varandra. Till exempel, i ett operativsystem kan en applikation tillåtas att styra I/O-enheter, i ett annat är dessa åtgärder operativsystemets privilegium.
Varje operativsystem har sina egna resursskyddsmekanismer, sina egna fel- och undantagshanteringsalgoritmer, sin egen processorstruktur och minneshanteringsschema, sin egen filåtkomstsemantik och sitt eget grafiska användargränssnitt. För att säkerställa kompatibilitet är det nödvändigt att organisera en konfliktfri samexistens inom samma OS av flera sätt att hantera datorresurser.
Det finns olika alternativ för att bygga flera applikationsmiljöer, som skiljer sig både i egenskaper hos arkitektoniska lösningar och i funktionalitet som ger varierande grad av applikationsportabilitet. Ett av de mest uppenbara alternativen för att implementera flera applikationsmiljöer är baserat på operativsystemets standardlagerstruktur.
Ett annat sätt att bygga flera applikationsmiljöer är baserat på mikrokärnmetoden. Samtidigt är det mycket viktigt att notera den grundläggande, gemensamma för alla applikationsmiljöer, skillnaden mellan operativsystemets mekanismer och de högnivåfunktioner som är specifika för var och en av applikationsmiljöerna som löser strategiska problem. I enlighet med mikronukleär arkitektur alla OS-funktioner implementeras av mikrokärnan och användarlägesservrarna. Det är viktigt att applikationsmiljön är utformad som en separat användarlägesserver och inte inkluderar de underliggande mekanismerna.
Applikationer, med hjälp av API:et, gör systemanrop till motsvarande applikationsmiljö genom mikrokärnan. Applikationsmiljön bearbetar begäran, exekverar den (kanske genom att be om hjälp från mikrokärnans grundläggande funktioner för detta), och skickar resultatet tillbaka till applikationen. Under utförandet av begäran måste applikationsmiljön i sin tur komma åt de underliggande OS-mekanismerna som implementeras av mikrokärnan och andra OS-servrar.
Denna metod för att designa flera applikationsmiljöer har alla fördelar och nackdelar med mikrokärnarkitektur, i synnerhet:
- det är mycket enkelt att lägga till och utesluta applikationsmiljöer, vilket är en konsekvens av den goda utökbarheten hos mikrokärnoperativsystem;
- om en av applikationsmiljöerna misslyckas förblir resten i drift, vilket bidrar till systemets tillförlitlighet och stabilitet som helhet;
- låg prestanda hos mikrokärnoperativsystem påverkar applikationsverktygens hastighet och därmed applikationernas hastighet.
Som ett resultat bör det noteras att skapandet inom ett operativsystem av flera applikationsverktyg för att köra applikationer från olika operativsystem är ett sätt som gör att du kan ha en enda version av programmet och överföra det mellan olika operativsystem. Flera applikationsmiljöer säkerställer binär kompatibilitet för ett givet operativsystem med applikationer skrivna för andra operativsystem.
1.9. Virtuella maskiner som ett modernt tillvägagångssätt för implementering av flera applikationsmiljöer
Begreppet "virtual machine monitor" (VMM) uppstod i slutet av 60-talet som en mjukvara abstraktionsnivå, som delade upp hårdvaruplattformen i flera virtuella maskiner. Var och en av dessa virtuella maskiner (VM) var så lik den underliggande fysiska maskinen att den existerande programvara kunde utföras på den oförändrad. På den tiden, beräkningsproblem allmän löstes på dyra stordatorer (som IBM/360), och användare berömde VMM:s förmåga att allokera knappa resurser mellan flera applikationer.
Under 1980- och 1990-talen sjönk kostnaderna avsevärt. datorutrustning och effektiv multitasking OS, vilket minskade värdet på VMM i användarnas ögon. Stordatorer gav vika för minidatorer, och sedan PC, och behovet av en VMM försvann. Som ett resultat försvann datorarkitekturen helt enkelt hårdvara för deras effektiva genomförande. I slutet av 80-talet, inom vetenskapen och i produktionen av VMM, uppfattades de bara som en historisk kuriosa.
Idag är MVM tillbaka i rampljuset. Intel, AMD, Sun Microsystems och IBM skapar virtualiseringsstrategier, och labb och universitet utvecklar virtuella maskinbaserade metoder för att hantera problem med mobilitet, säkerhet och hanterbarhet. Vad hände mellan MVM:s avgång och deras återupplivande?
På 1990-talet började forskare vid Stanford University undersöka möjligheten att använda virtuella maskiner för att övervinna begränsningarna hos hårdvara och operativsystem. Problem uppstod med datorer med massivt parallell bearbetning (Massively Parallel Processing, MPP), som var svåra att programmera och inte kunde köra befintliga operativsystem. Forskarna fann att virtuella maskiner kunde göra denna besvärliga arkitektur tillräckligt lik befintliga plattformar för att dra fördel av vanliga operativsystem. Från detta projekt kom människorna och idéerna som blev guldgruvan för VMware (www.vmware.com), den första leverantören av VMM:er för vanliga datorer.
Märkligt nog ledde utvecklingen av moderna operativsystem och sjunkande hårdvarukostnader till problem som forskarna hoppades kunna lösa med VMM. Den billiga utrustningen bidrog till den snabba spridningen av datorer, men de var ofta underutnyttjade, vilket krävde extra utrymme och ansträngning att underhålla. Och konsekvenserna av tillväxten av operativsystemets funktionalitet har blivit deras instabilitet och sårbarhet.
För att minska effekten av systemkrascher och skydda mot hackor, systemadministratörer vände tillbaka till single-tasking beräkningsmodell(med en applikation på en maskin). Detta resulterade i extra kostnader på grund av ökade hårdvarukrav. Att flytta applikationer från olika fysiska maskiner till virtuella datorer och konsolidera dessa virtuella datorer på ett fåtal fysiska plattformar har förbättrat hårdvaruanvändningen, minskat hanteringskostnaderna och minskat golvyta. Sålunda har VMM:s förmåga att multiplexera hårdvara – den här gången i namn av serverkonsolidering och verktygsdatorer – väckt dem till liv igen.
För närvarande har VMM inte så mycket blivit ett verktyg för att organisera multitasking som det en gång var tänkt, utan en lösning på problemen med att säkerställa säkerhet, mobilitet och tillförlitlighet. På många sätt ger VMM operativsystemsutvecklare möjligheten att utveckla funktionalitet som inte är möjlig med dagens komplexa operativsystem. Funktioner som migrering och skydd är mycket bekvämare att implementera på VMM-nivå, vilket bibehåller bakåtkompatibilitet vid implementering av innovativa operativsystemlösningar samtidigt som tidigare prestationer bibehålls.
Virtualisering är en teknologi under utveckling. Generellt sett låter virtualisering dig separera programvaran från den underliggande hårdvaruinfrastrukturen. Faktum är att det bryter kopplingen mellan en viss uppsättning program och en specifik dator. Virtual Machine Monitor separerar programvara från hårdvaran och bildar en mellannivå mellan mjukvara som körs virtuella maskiner, och hårdvara. Denna nivå tillåter VMM att helt kontrollera användningen av hårdvaruresurser. gästoperativsystem (GuestOS) som körs på den virtuella datorn.
VMM skapar en enhetlig bild av den underliggande hårdvaran så att fysiska maskiner från olika leverantörer med olika I/O-undersystem ser likadana ut och den virtuella datorn körs på all tillgänglig hårdvara. Genom att inte bry sig om enskilda maskiner med deras täta sammankopplingar mellan hårdvara och mjukvara kan administratörer helt enkelt se hårdvaran som en pool av resurser för att tillhandahålla alla on-demand-tjänster.
Tack vare full inkapsling programvarutillstånd på den virtuella datorn kan VMM-monitorn mappa den virtuella datorn till alla tillgängliga hårdvaruresurser och till och med flytta den från en fysisk maskin till en annan. Uppgiften med lastbalansering över en grupp av maskiner blir trivial, och det finns pålitliga sätt att hantera hårdvarufel och utöka systemet. Om du behöver stänga av en defekt dator eller sätta en ny online igen, kan VMM omfördela de virtuella maskinerna därefter. Den virtuella maskinen är lätt att replikera, vilket gör att administratörer snabbt kan tillhandahålla nya tjänster efter behov.
Inkapsling innebär också att administratören kan pausa eller återuppta den virtuella datorn när som helst, samt spara det aktuella tillståndet för den virtuella maskinen eller återställa det till föregående tillstånd. Med universell ångringsfunktion kan krascher och konfigurationsfel enkelt hanteras. Inkapsling är grunden för en generaliserad mobilitetsmodell, eftersom en suspenderad virtuell dator kan kopieras över nätverket, lagras och transporteras på flyttbara media.
VMM spelar rollen som en mellanhand i all interaktion mellan den virtuella datorn och den underliggande hårdvaran, vilket stöder exekvering av många virtuella maskiner på en enda hårdvaruplattform och säkerställer deras tillförlitliga isolering. VMM låter dig sätta ihop en grupp virtuella datorer med låga resurskrav på en enda dator, vilket minskar kostnaderna för hårdvara och behovet av produktionsutrymme.
Fullständig isolering är också viktigt för tillförlitlighet och säkerhet. Applikationer som tidigare kördes på en enda dator kan nu distribueras över olika virtuella datorer. Om en av dem orsakar en OS-krasch som ett resultat av ett fel, kommer andra applikationer att isoleras från det och fortsätta att fungera. Om ett av programmen hotas av en extern attack, kommer attacken att lokaliseras inom den "komprometterade" virtuella datorn. Således är VMM ett verktyg för att omstrukturera systemet för att förbättra dess stabilitet och säkerhet, utan att kräva ytterligare utrymme och administrationsinsatser, vilket är nödvändigt när applikationer körs på separata fysiska maskiner.
VMM:n måste associera ett hårdvarugränssnitt med VM:n samtidigt som den behåller full kontroll över basmaskin och procedurer för att interagera med dess hårdvara. För att uppnå detta mål finns det olika metoder baserade på vissa tekniska kompromisser. När man söker efter sådana kompromisser beaktas huvudkraven för VMM: kompatibilitet, prestanda och enkelhet. Kompatibilitet är viktig eftersom den största fördelen med en VMM är möjligheten att köra äldre applikationer. Prestanda bestämmer mängden overhead för virtualisering - program på den virtuella datorn måste köras i samma hastighet som på den verkliga maskinen. Enkelhet är nödvändig eftersom fel på VMM kommer att resultera i fel på alla virtuella datorer som körs på datorn. I synnerhet kräver pålitlig isolering att VMM:n är fri från buggar som angripare kan använda för att förstöra systemet.
Istället för att gå igenom en komplex kodomskrivning av gästoperativsystemet kan du göra några ändringar i värdoperativsystemet genom att ändra några av de mest "störande" delarna av kärnan. Detta tillvägagångssätt kallas paravirtualisering. Det är tydligt att i det här fallet kan bara författaren anpassa OS-kärnan, och till exempel visar Microsoft ingen önskan att anpassa den populära Windows 2000-kärnan till verkligheten hos specifika virtuella maskiner.
Vid paravirtualisering omdefinierar VMM-utvecklaren gränssnittet för den virtuella maskinen, och ersätter en delmängd av den ursprungliga instruktionsuppsättningen som är olämplig för virtualisering med mer bekväma och effektiva motsvarigheter. Observera att även om operativsystemet måste porteras för att köras på sådana virtuella datorer, kan de flesta vanliga applikationerna köras oförändrade.
Den största nackdelen med paravirtualisering är inkompatibilitet. Några operativ system, designad för att köras under kontroll av en paravirtualiserad VMM-monitor, måste portas till denna arkitektur, för vilken det är nödvändigt att förhandla fram samarbete med OS-leverantörer. Dessutom kan äldre operativsystem inte användas, och befintliga maskiner kan inte enkelt ersättas med virtuella.
För att uppnå hög prestanda och kompatibilitet i x86-virtualisering har VMware utvecklat ny metod virtualisering som kombinerar traditionell direktexekvering med snabb binär översättning i farten. I de flesta moderna operativsystem är processorns driftsätt under exekvering av vanliga applikationsprogram lätt att virtualisera, och därför kan de virtualiseras genom direkt exekvering. Privilegerade lägen som är olämpliga för virtualisering kan exekveras av en binär kodöversättare, vilket korrigerar de "obekväma" x86-kommandona. Resultatet är en hög prestanda virtuell maskin, som är helt kompatibel med utrustningen och stöden full kompatibilitet FÖRBI .
Den konverterade koden är mycket lik resultaten av paravirtualisering. Vanliga kommandon utförs oförändrade, och kommandon som behöver specialbearbetning(såsom POPF och läs kodsegmentregisterinstruktioner), ersätter översättaren instruktionssekvenser som liknar de som krävs för att exekvera på en paravirtualiserad virtuell maskin. Det finns dock en viktig skillnad: istället för att förändra källa operativsystem eller applikationer ändrar den binära översättaren koden när den exekveras för första gången.
Även om det finns vissa extra kostnader för att översätta binär kod är de försumbara under normala arbetsbelastningar. Översättaren bearbetar bara en del av koden, och hastigheten för programexekveringen blir jämförbar med hastigheten för direkt exekvering - så snart cachen är full.
Kompatibilitet och flera applikationsmiljöer
Konceptet med flera applikationsmiljöer är relaterat till slutanvändarnas behov - operativsystemets förmåga att köra applikationer från andra operativsystem. Denna egenskap hos operativsystemet kallas kompatibilitet.
Binär och källkompatibilitet
Skilj mellan kompatibilitet på binär nivå och kompatibilitet på källkodsnivå. Applikationer lagras vanligtvis i operativsystemet som körbara filer som innehåller binära bilder av kod och data. Binär kompatibilitet uppnås när du kan ta ett körbart program och köra det på ett annat operativsystem.
Kompatibilitet på källnivå kräver att lämplig kompilator ingår i programvaran på den dator som programmet är tänkt att köras på, liksom kompatibilitet på nivån för bibliotek och systemanrop. Detta kräver att den tillgängliga källkoden kompileras till en körbar modul.
Kompatibilitet på källnivå är viktig främst för applikationsutvecklare som har dessa källor till sitt förfogande. För slutanvändare är endast binär kompatibilitet av praktisk betydelse, eftersom de endast i detta fall kan använda samma kommersiella produkt i binär form. körbar kod i olika driftsmiljöer.
Huruvida operativsystem är binärt kompatibla eller källkompatibla beror på många faktorer. Den främsta bland dem är arkitekturen för processorn som det nya operativsystemet körs på. Om processorn använder samma instruktionsuppsättning (kanske med några tillägg) och samma adressintervall, kan binär kompatibilitet uppnås ganska enkelt. För att göra detta är det tillräckligt att följa följande villkor:
Anrop till API-funktioner som en applikation innehåller måste stödjas av operativsystemet;
Den interna strukturen för den körbara applikationsfilen måste matcha strukturen för de körbara operativsystemfilerna.
Det är svårare att uppnå binär kompatibilitet för operativsystem utformade för att köras på processorer med olika arkitekturer. Förutom att observera ovanstående villkor är det nödvändigt att organisera emulering av den binära koden, vilket kommer att leda till en ganska långsam programexekvering.
Att skapa en komplett applikationsmiljö som är helt kompatibel med miljön i ett annat operativsystem är en uppgift som är nära relaterad till operativsystemets struktur. Det finns olika alternativ för att bygga flera applikationsmiljöer, som skiljer sig både i egenskaper hos arkitektoniska lösningar och i funktionalitet som ger varierande grad av applikationsportabilitet.
Ett av de mest uppenbara alternativen för att implementera flera applikationsmiljöer är baserat på den standardskiktade OS-strukturen och tillhandahåller systemanropsöversättning.
I figur 6 stöder operativsystemet OS1, förutom sina applikationer, applikationerna för operativsystemen OS2 och OS3.
För att göra detta innehåller den speciella applikationer - programvarumiljöer - som översätter gränssnitten för "främmande" operativsystem API OS2 och API OS3 till gränssnittet för deras operativsystem - API OS1.
Figur 6 - Applikationsmiljöer som översätter systemanrop
I en annan implementering av flera applikationsmiljöer har operativsystemet flera peer-applikationsprogrammeringsgränssnitt (Figur 7). I exemplet som visas stöder operativsystemet applikationer för OS1, OS2 och OS3.
För att göra detta placeras applikationsprogrammeringsgränssnitten för alla dessa operativsystem direkt i systemets kärna: API OS1, API OS2 och API OS3.
Figur 7 - Implementering av kompatibilitet baserad på flera peer-API:er
I denna variant anropar API-nivåfunktionerna funktionerna för den underliggande OS-nivån, som måste stödja alla tre generellt inkompatibla applikationsmiljöer. Funktionerna för varje API implementeras av kärnan, med hänsyn till specifikationerna för motsvarande OS, även om de har ett liknande syfte. För att kärnan ska kunna välja önskad implementering av ett systemanrop måste varje process skicka en uppsättning identifierande egenskaper till kärnan.
Ett annat sätt att bygga flera applikationsmiljöer är baserat på mikrokärnmetoden. I enlighet med mikrokärnarkitekturen implementeras alla OS-funktioner av mikrokärnan och användarlägesservrarna. Varje applikationsmiljö är utformad som en separat server i användarläge och inkluderar inte grundläggande mekanismer (Figur 8). Applikationer gör systemanrop till lämplig applikationsmiljö genom mikrokärnan. Applikationsmiljön bearbetar begäran, exekverar den och skickar tillbaka resultatet till applikationen. Under utförandet av begäran måste applikationsmiljön i sin tur komma åt de underliggande OS-mekanismerna som implementeras av mikrokärnan och andra OS-servrar.
Denna metod för att designa flera applikationsmiljöer har alla fördelar och nackdelar med en mikrokärnarkitektur, i synnerhet:
Det är mycket enkelt att lägga till och ta bort applikationsmiljöer, vilket är en konsekvens av den goda utökbarheten hos mikrokärnoperativsystem;
Tillförlitlighet och stabilitet uttrycks i det faktum att om en av applikationsmiljöerna misslyckas, förblir alla andra i drift;
Den låga prestandan hos mikrokärnoperativsystem påverkar applikationsmiljöernas hastighet och därmed hastigheten på applikationsexekveringen.
Figur 8 - Mikrokärnans tillvägagångssätt för att implementera flera applikationsmiljöer
Skapandet inom ett operativsystem av flera applikationsmiljöer för exekvering av applikationer av olika operativsystem är ett sätt som låter dig ha en enda version av programmet och överföra det mellan operativsystem.