Introduksjon til operativsystemer
Martin Gilje Jaatun
30. april 2007
Sammendrag
Dette dokumentet er et forsøk på å formidle noen velmenende formuleringer omoperativsystemet, dvs. kapittel 1 i [Tan01a]. Dokumentet er for det meste basert på[Tan01b], som er foiler utarbeidet av forfatteren av [Tan01a].
Den observante leser vil ha registrert at dokumentet er skrevet på norsk, og nors-ke uttrykk er derfor forsøkt brukt gjennomgående. Imidlertid er etablerte engelskeforkortelser beholdt.
Innhold
Innledning 3
1 Historisk tilbakeblikk 4
1.1 Generasjoner av datamaskiner . . . . . . . . . . . . . . . . . . . . . . 41.2 Satsvise systemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Multiprogrammering . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Ikke bare Arnardo og Merano 6
3 Noen sentrale maskinvarebegreper 7
3.1 Henry Ford hadde vært stolt . . . . . . . . . . . . . . . . . . . . . . 73.2 Minnehierarki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Harddisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4 Deling av programkode . . . . . . . . . . . . . . . . . . . . . . . . . . 93.5 Avbrudd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.6 Gode busser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Operativsystemkonsepter 10
4.1 Prosesser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Vranglås . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Filer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1
5 Systemkall 15
5.1 Prosessadministrasjon . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Fil- og katalogadministrasjon . . . . . . . . . . . . . . . . . . . . . . 185.3 Unix vs. Win32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 OS struktur 20
7 Litt metrikk til slutt 22
A Ordliste 23
Figurer
1 Hva består et datamaskinsystem av? . . . . . . . . . . . . . . . . . . 32 Operasjoner involvert i en satsvis kjøring av et program . . . . . . . 53 Struktur på en typisk FMS-jobb . . . . . . . . . . . . . . . . . . . . 64 Multiprogrammering: Tre jobber i minnet på en gang . . . . . . . . . 75 Grovskisse over komponenter i en enkel PC . . . . . . . . . . . . . . 86 (a) En tre-trinns rørledning (b) En superscalar CPU . . . . . . . . . 87 Typisk minnehierarki . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Innvendig struktur på en harddisk . . . . . . . . . . . . . . . . . . . 109 Effekten av å dele programkode mellom flere prosesser . . . . . . . . 1110 Starting av en I/O-enhet og mottak av avbrudd, og hvordan dette ser ut for programmet 1211 Blokkskjema for en moderne Pentium PC . . . . . . . . . . . . . . . 1312 Et prosesstre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313 En potensiell vranglås og en manifest vranglås . . . . . . . . . . . . 1414 Et filsystem for en høgskoleavdeling . . . . . . . . . . . . . . . . . . 1415 Montering av filsystem . . . . . . . . . . . . . . . . . . . . . . . . . . 1516 To prosesser koblet sammen med et rør . . . . . . . . . . . . . . . . 1517 11 steg for å utføre systemkallet read(fd,buffer,nbytes) . . . . . 1618 Et utvalg av de viktigste POSIX systemkallene . . . . . . . . . . . . 1719 Et minimalistisk skall . . . . . . . . . . . . . . . . . . . . . . . . . . 1720 De tre segmentene assosiert med en prosess . . . . . . . . . . . . . . 1821 To kataloger før og etter opprettelsen av lenken “note” . . . . . . . . 1922 Sammenligning mellom Unix og Win32 API systemkall . . . . . . . . 1923 En enkel strukturmodell for et monolittisk system . . . . . . . . . . 2024 Struktur for THE OS . . . . . . . . . . . . . . . . . . . . . . . . . . 2025 Struktur for VM/370 med CMS . . . . . . . . . . . . . . . . . . . . . 2126 Klient/tjener-modellen for en mikrokjernearkitektur . . . . . . . . . 2127 Klient/tjener-modellen for et distribuert system . . . . . . . . . . . . 21
2
Figur 1: Hva består et datamaskinsystem av?
Innledning
Som det fremgår av fig. 1, består et datamaskinsystem av maskinvare, systempro-gramvare og applikasjonsprogramvare. Maskinvaren omfatter de fysiske enhetene(mikroprosessor, harddisk, RAM-brikker, etc.), men også mikroarkitektur (f.eks. ien mikroprosessor) og maskinspråket som den aktuelle mikroprosessoren “forstår”.Applikasjonsprogramvare kan grovt sett beskrives som programmer som startes av“vanlige brukere”, og kan være alt fra spill, via nettlesere, til (som i figuren) etreservasjonssystem for et flyselskap.
Systemprogramvare er kanskje den mest “vage” av de tre hovedkomponentene. Selvom kompilatorer, editorer og skall (command interpreters) strengt tatt ikke er en delav operativsystemet, er de ofte så tett integrert med dette at brukeren oppfatter demsom to sider av samme sak. I enkelte tilfeller ser vi at det er glidende overganger,og systemprogrammer som ikke er en del av operativsystemet vil vanligvis likevelha ganske tett interaksjon med det. Av denne grunn vil dette faget også ta forseg en del praktisk bruk av slike systemprogrammer, spesielt i konteksten script-programmering og bruk av systemkall.
Hva er så egentlig et operativsystem? Vår venn [Tan01a] presenterer to alternative
3
abstraksjoner som utfyller hverandre: Et OS er en utvidet datamaskin, eller et OSer en ressursadministrator. I forskjellige sammenhenger vil vi se at enten den eneeller den andre abstraksjonen føles mest “riktig”.
Det at vi ser på operativsystemet som en utvidet datamaskin betyr at det skjulerde “skitne” detaljene i alt arbeidet som må gjøres når datamaskinen skal utføre sineoppgaver. Operativsystemet presenterer en “virtuell maskin” på et høyere abstrak-sjonsnivå for brukeren, noe som gjør systemet enklere å bruke (på samme måte somat de fleste av oss synes det er enklere å programmere i et høynivå programmerings-språk som Java enn å programmere i assembler).
Abstraksjonen med operativsystemet som ressursadministrator (resource manager)har sin bagrunn i at når flere brukere (eller prosesser) skal ha tilgang til en data-maskin samtidig, er det noen som må sørge for at dette skjer i henhold til nærmeredefinerte regler. Ofte vil man forsøke å gjøre dette så “rettferdig” som mulig, dvs. athvert program får sin tid (etter tur) til å bruke ressurser som disk, printer, skjerm,etc., samt at hvert program får sin tildelte plass på de ressursene hvor dette errelevant (disk, minne, etc.)
1 Historisk tilbakeblikk
Det har skjedd en del på operativsystemfronten siden de første datamaskinene sådagens lys midt på 40-tallet. De første datamaskinene hadde egentlig ikke operativ-system i det hele tatt, og da operativsystemene dukket opp, hadde de først betydeligmindre funskjonalitet enn det vi forventer i dag.
1.1 Generasjoner av datamaskiner
Boka deler datamaskin-historien inn i fire generasjoner:
1. 1945-1955
2. 1955-1965
3. 1965-1980
4. 1980- i dag
Første generasjon kan som nevnt knapt sies å ha hatt operativsystemer, og var ka-rakterisert ved bruk av radio-rør (vacum tubes) og “programmering” ved hjelp avsammenkobling av ledninger på såkalte plugge-brett (plug boards) – tilsvarende etgammelt manuelt sentralbord. Andre generasjon tok i bruk transistorer og satsvisesystem, mens tredje generasjon var karakterisert ved integrerte kretser og multi-programmering. Den fjerde generasjonen startet med lanseringen av IBMs PersonalComputer, og verden har som kjent ikke vært den samme siden.
4
Figur 2: Operasjoner involvert i en satsvis kjøring av et program
1.2 Satsvise systemer
I fig. 2 ser vi den manuelle og tidkrevende prosessen det var å kjøre et program i etsatsvis system (batch system). Først måtte programmereren skrive programmet påen stabel med små hullkort vha. en spesiell “skrivemaskin” (ikke vist på figuren).Deretter måtte programmereren bære stabelen til en egen kortleser koblet til enliten datamaskin (kalt 1401 i figuren), hvor hullkortene ble lest, og informasjonenskrevet over på magnetisk tape. Denne tapen ble så båret fra 1401-maskinen til 7094-maskinen, hvor programmet ble lest inn og de faktiske beregningene i programmetble utført. Resultatet ble skrevet til en nye tape, som deretter måtte flyttes til ennye 1401-maskin som kunne lese tapen og skrive resultatene ut på en printer.
Det var vanligvis en betydelig forsinkelse fra man leverte kortene ((a) i figuren) tilman fikk resultatet (etter (f)); ettersom datamaskiner var sinnsykt dyre, var detvanligvis en lang kø med jobber som skulle utføres, slik at arbeidsmønsteret for ensatsvis programmerer gjerne ble slik man nå forbinder med installering av Linux:Lever jobb – spis lunsj (evt. også middag) – sjekk resultat. Dersom det var en litenfeil i programmet, medførte det (da som nå) at hele greia kræsjet, men til forskjellfra i dag medførte dette igjen timevis med tapt arbeidstid.
De første satsvise systemene kunne bare programmeres i maskinspråk, men etterhvert fikk man mer høynivå programmeringsspråk som FORTRAN. På dette tids-punktet hadde man fremdeles bare veldig enkle operativsystemer som Fortran Moni-tor System (FMS), som ikke hadde stort større funksjonalitet enn å lese inn program-koden, kjøre FORTRAN-kompilatoren, og kjøre det resulterende programmet medda vedlagte data. Hvordan hullkortene i en slik jobb kunne struktureres er illustrerti fig. 3.
5
Figur 3: Struktur på en typisk FMS-jobb
1.3 Multiprogrammering
De satsvise systemene var ganske maskuline – de kunne bare gjøre en ting om gan-gen. Multiprogrammeringen som ble introdusert i tredje generasjon gjorde det muligfor en datamaskin å ha flere forskjellige programmer lastet inn i minnet samtidig –i tillegg til selve operativsystemet. Dette vises i fig. 4.
2 Ikke bare Arnardo og Merano
I dag har vi det reneste sirkus1 av operativsystemer å forholde oss til. Eksemplernevnes i fleng:
• Stormaskin (mainframe) OS
• Tjener (server) OS
• Multiprosessor OS
• OS for personlige datamaskiner
• OS for håndholdte datamaskiner (PDA)
• Sanntids OS
1Som illustrert på forsiden av [Tan01a] – til tross for at Andy selv kaller det the operating system zoo
6
Figur 4: Multiprogrammering: Tre jobber i minnet på en gang
• Innebygde (embedded) OS
• Smartkort OS
I de følgende kapitlene vil vi se nærmere på en del av disse, men for det meste vilvi bevege oss på det generelle plan.
3 Noen sentrale maskinvarebegreper
I dette avsnittet presenterer vi noen sentrale maskinvarebegreper som forhåpentlig-vis burde være kjent for de fleste.
I fig. 5 vises det en forenklet oversikt over typiske komponenter i en personlig data-maskin. Mikroprosessoren (Central Processing Unit – CPU) er datamaskinens hjer-ne, og alle former for beregninger utføres her. Program og data lagres i (primær-)minnet under kjøring, og meldinger til brukeren skrives ut på skjermen. Brukerenskriver sine kommandoer til datamaskinen på tastaturet (og i våre dager har mandessuten vanligvis en mus), og flytter på programmer og data vha. flyttbare mediasom disketter. Langtidslagring av programmer og data skjer på harddisken.
3.1 Henry Ford hadde vært stolt
Moderne mikroprosessorer bruker forskjellige teknikker for å effektivisere utførselenav instruksjoner. Fig. 6 a) viser en samlebåndsteknikk vi kan kalle en rørledning(pipeline). Her er egne komponenter for å hente neste instruksjon, for å dekode
7
Figur 5: Grovskisse over komponenter i en enkel PC
Figur 6: (a) En tre-trinns rørledning (b) En superscalar CPU
instruksjonen, og for å utføre instruksjonen. Poenget med denne teknikken (pipeli-ning), er at når første instruksjon er hentet, og sendt videre til dekoding, kan mangå ut og hente neste instruksjon, uten å vente på at den første instruksjonen erferdig utført.
En superscalar CPU som vist i fig. 6 b) tar dette konseptet et hakk videre ved åha flere parallelle hente-og-dekode-køer som ender opp i flere (muligens spesialiser-te) utførselsenheter. For enkelte applikasjoner kan dette gi en veldig stor grad avparallellitet, med tilsvarende ytelsesforbedring.
8
Figur 7: Typisk minnehierarki
3.2 Minnehierarki
Prisen på minne er (grovt sett) proporsjonal med hastigheten, og i praksis betyrdette størrelsen (som man har råd til) av hver minnetype er omvendt proporsjonalmed hastigheten. Den aller raskeste minnetypen er registrene som er en integrertpå selve mikroprosessoren, men disse utgjør totalt mindre enn 1kB lagringsplass.Deretter kommer hurtiglager (cache) på rundt 1 MB, primærlager (RAM) rundt1GB, sekundærlager (harddisk) på rundt 200 GB. Installasjoner med store data-og/eller sikkerhetskopieringsbehov har dessuten tertiærlager (tape) med terabytepå terabyte.
3.3 Harddisk
Fig. 8 viser skjematisk hvordan den interne oppbygningen til en harddisk ser ut.
3.4 Deling av programkode
Multiprogrammering gjør det som kjent mulig å ha flere prosesser kjørende samtidig,og en naiv implementasjon av dette gir et bilde som i fig. 9 a), hvor hver prosesshar tildelt et minneområde som inneholder programkode (text segment) og data.Operativsystemet holder greie på området som er tildelt hver prosess vha. to registre,base og limit, som angir adresseintervallet tildelt prosessen.
Så lenge prosessene utfører forskjellige programmer, er dette greit nok, men hvisflere prosesser kjører samme program, er det litt bortkastet å bruke minne til ålagre flere kopier av en programkode som ikke endrer seg. Dette løses i fig. 9 b),hvor man bruker fire registre: base-1 og limit-1 angir tekstsegmentet, mens base-2 oglimit-2 angir dataområdet. Når operativsystemet bytter mellom prosess 1 og prosess
9
Figur 8: Innvendig struktur på en harddisk
2, vil innholdet i base-1 og limit-1 forbli uendret, mens innholdet i base-2 og limit-2endres til å peke på dataområdet til prosess 2.
3.5 Avbrudd
I mange tilfeller vil aksess til I/O-enheter være avbruddsdrevet, dvs. at prosessorenvil initiere en I/O-operasjon til disk og deretter fortsette å gjøre andre ting uten åvente på resultatet. Når I/O-operasjonen er ferdig, vil enheten (disk-kontrolleren ifig. 10 a) ) generere et avbrudd som håndteres av avbruddshåntereren, og som igjenaktiverer CPU-ens avbruddslinje.
3.6 Gode busser
En moderne Pentium-basert PC har et utall forskjelige busser på hovedkortet, somillustrert på fig. 11.
4 Operativsystemkonsepter
Bortsett fra at dette er tittelen på en konkurrerende lærebok, dekker dette uttrykketen del fundamentale begreper som man må mestre dersom man skal ha noe håp omå forstå de mest vesentlige aspekter ved operativsystemfaget.
10
Figur 9: Effekten av å dele programkode mellom flere prosesser
4.1 Prosesser
I mange operativsystemer har man et hierarki av prosesser, som vist i fig. 12. Her harA opprettet to barneprosesser B og C, mens B igjen har opprettet tre barneprosesserD, E og F.
4.2 Vranglås
Når flere prosesser skal ha tilgang til de samme ressursene på samme tidspunkt,risikerer man at det oppstår vranglås (deadlock). I fig. 13 illustreres hvordan enklassisk vranglås i den virkelige verden kan oppstå i et veikryss – med norsk høyre-regel og overdrevent høflige sjåfører har man i praksis en vranglås allerede i førstedel av figuren.
4.3 Filer
Filer er et sentralt begrep for alle operativsystemer, og for enkelte mer enn andre.Filer organiseres gjerne hierarkisk i en katalogstruktur som illustrert i fig. 14.
I Unix er det mulig å “montere” inn filsystemer fra forskjellige partisjoner eller
11
Figur 10: Starting av en I/O-enhet og mottak av avbrudd, og hvordan dette ser ut forprogrammet
12
ISA bridge
Modem
Mouse
PCI bridgeCPU
Main memory
SCSI USB
Local bus
Sound card Printer Available
ISA slot
ISA bus
IDE disk
Available PCI slot
Key- board
Mon- itor
Graphics adaptor
Level 2 cache
Cache bus Memory bus
PCI bus
Figur 11: Blokkskjema for en moderne Pentium PC
A
B
D E F
C
Figur 12: Et prosesstre
13
(a) (b)
Figur 13: En potensiell vranglås og en manifest vranglås
Root directory
Students Faculty
Leo Prof.Brown
Files
Courses
CS101 CS105
Papers Grants
SOSP COST-11
Committees
Prof.Green Prof.WhiteMattyRobbert
Figur 14: Et filsystem for en høgskoleavdeling
14
Root Floppy
a b
c d c d
a bx y
x y
(a) (b)
Figur 15: Montering av filsystem
ProcessPipe
Process
A B
Figur 16: To prosesser koblet sammen med et rør
fysiske disker, slik at alt blir en del av ett stort filsystemhierarki. Dette illustreres ifig. 15, hvor filsystemet på en diskett monteres inn i hovedfilsystemet til en maskin.
Under Unix er det mer enn bare det vi tradisjonelt anser som filer som omfattesav fil-sematikken. F.eks. innen et C-program vil man ofte ha variable som lignerpå fildeskriptorer som behandles helt analogt til filer (skriving, lesing, etc.), mensom egentlig er noe annet. Et eksempel på dette er “rør”-konseptet (pipe), illustrertpå fig. 16. Dersom to prosesser ønsker å kommunisere med hverandre, kan dettegjøres via et rør, som må være satt opp på forhånd. Vanligvis gjøres dette ved aten mor-prossess oppretter røret før den oppretter barneprosessen med fork(). Nårbarneprosessen starter opp, har den en kopi av alle morens variable – inkludertrøret, som den da kan begynne å bruke.
5 Systemkall
Grensesnittet mellom operativsystemet og brukerprogram er definert ved et sett avsystemkall.
I fig. 17 vises det hvilke trinn man må gå gjennom for å lese nbytes byte fra filensom pekes på av fildeskriptoren fd inn i bufferet buffer (dvs. utføre systemkalletread(fd,buffer,nbytes)):
1. nbytes dyttes på stakken
15
Return to caller
410
6
0
9
7 8
321
11
DispatchSys call handler
Address 0xFFFFFFFF
User space
Kernel space (Operating system)
Library procedure read
User program calling read
Trap to the kernelPut code for read in register
Increment SPCall readPush fdPush &bufferPush nbytes
5
Figur 17: 11 steg for å utføre systemkallet read(fd,buffer,nbytes)
2. adressen til buffer dyttes på stakken
3. fd dyttes på stakken
4. biblioteksrutinen for systemkallet read kalles
5. legg koden for read i register
6. overgang (trap) til kjernen
7. kjernen finner via systemkallets nummer ut hvilken håndteringsrutine (systemcall handler) som skal kjøres
8. den aktuelle håndteringsrutinen kjøres
9. returner til biblioteksrutinen
10. returner til bruker program
11. “rydder opp” ved å inkrementere stakk-pekeren (SP) slik at man er tilbake tiltilstanden før nbytes etc. ble stappet inn i den.
Fig. 18 viser de viktisgste POSIX systemkallene, som både støttes av Unix, Linuxog (i større eller mindre grad) Windows 2000/XP.
16
Process management22222222222222222222222222222222222222222222222222222222222222222222222222222222222Call Description22222222222222222222222222222222222222222222222222222222222222222222222222222222222
pid = fork( ) Create a child process identical to the parent22222222222222222222222222222222222222222222222222222222222222222222222222222222222pid = waitpid(pid, &statloc, options) Wait for a child to terminate22222222222222222222222222222222222222222222222222222222222222222222222222222222222s = execve(name, argv, environp) Replace a process’ core image22222222222222222222222222222222222222222222222222222222222222222222222222222222222exit(status) Terminate process execution and return status222222222222222222222222222222222222222222222222222222222222222222222222222222222221111111
1111111
1111111
File management22222222222222222222222222222222222222222222222222222222222222222222222222222222222Call Description22222222222222222222222222222222222222222222222222222222222222222222222222222222222
fd = open(file, how, ...) Open a file for reading, writing or both22222222222222222222222222222222222222222222222222222222222222222222222222222222222s = close(fd) Close an open file22222222222222222222222222222222222222222222222222222222222222222222222222222222222n = read(fd, buffer, nbytes) Read data from a file into a buffer22222222222222222222222222222222222222222222222222222222222222222222222222222222222n = write(fd, buffer, nbytes) Write data from a buffer into a file22222222222222222222222222222222222222222222222222222222222222222222222222222222222position = lseek(fd, offset, whence) Move the file pointer22222222222222222222222222222222222222222222222222222222222222222222222222222222222s = stat(name, &buf) Get a file’s status information222222222222222222222222222222222222222222222222222222222222222222222222222222222221111111111
1111111111
1111111111
Directory and file system management22222222222222222222222222222222222222222222222222222222222222222222222222222222222Call Description22222222222222222222222222222222222222222222222222222222222222222222222222222222222
s = mkdir(name, mode) Create a new directory22222222222222222222222222222222222222222222222222222222222222222222222222222222222s = rmdir(name) Remove an empty directory22222222222222222222222222222222222222222222222222222222222222222222222222222222222s = link(name1, name2) Create a new entry, name2, pointing to name122222222222222222222222222222222222222222222222222222222222222222222222222222222222s = unlink(name) Remove a directory entry22222222222222222222222222222222222222222222222222222222222222222222222222222222222s = mount(special, name, flag) Mount a file system22222222222222222222222222222222222222222222222222222222222222222222222222222222222s = umount(special) Unmount a file system2222222222222222222222222222222222222222222222222222222222222222222222222222222222211
11111111
1111111111
1111111111
Miscellaneous2222222222222222222222222222222222222222222222222222222222222222222222222222222222Call Description2222222222222222222222222222222222222222222222222222222222222222222222222222222222
s = chdir(dirname) Change the working directory2222222222222222222222222222222222222222222222222222222222222222222222222222222222s = chmod(name, mode) Change a file’s protection bits2222222222222222222222222222222222222222222222222222222222222222222222222222222222s = kill(pid, signal) Send a signal to a process2222222222222222222222222222222222222222222222222222222222222222222222222222222222seconds = time(&seconds) Get the elapsed time since Jan. 1, 197022222222222222222222222222222222222222222222222222222222222222222222222222222222221
111111
1111111
1111111
Figur 18: Et utvalg av de viktigste POSIX systemkallene
while (TRUE) { /* repeat forever */
type_prompt( ); /* display prompt */
read_command (command, parameters) /* input from terminal */
if (fork() != 0) { /* fork off child process */
/* Parent code */
waitpid( -1, &status, 0); /* wait for child to exit */
} else {
/* Child code */
execve (command, parameters, 0);/* execute command */
}
}
Figur 19: Et minimalistisk skall
17
����������������Address (hex)FFFF
0000
Stack
Data
Text
Gap
Figur 20: De tre segmentene assosiert med en prosess
5.1 Prosessadministrasjon
Generel anses prosesser for å ha tre segmenter: Tekst-segmentet inneholder pro-gramkoden, data-segmentet (også kjent som heap) inneholder variablene, og stakk-segmentet (pussig nok) stakken. Disse segmentene trenger ikke være allokert konti-nuerlig (som indikert i fig. 9), men det er vanlig at stakk- og data-segmentet hengersammen med en blokk med ledig plass i mellom, slik at de kan “vokse mot hverand-re”. Dette er illustrert i fig. 20.
5.2 Fil- og katalogadministrasjon
Unix har konseptet harde og myke “lenker” (links). I fig. 21 vises effekten av å lageen hard lenke note til katalogen /usr/jim/memo fra katalogen /usr/ast. Vi serat /usr/jim/memo har samme ID som /usr/ast/note, noe som betyr at de er tolikeverdige referanser til den samme fysiske filen (eller katalogen).
5.3 Unix vs. Win32
I fig. 22 vises en sammenligning mellom Unix systemkall og tilsvarende kall i Win32API. Her er det viktig å merke seg at forfatteren begrenser seg til det som støttesav f.eks. Windows 98, og ikke skjeler til f.eks. Windows 2000. Dette vil vi imidlertidkomme tilbake til mot slutten av boka.
18
/usr/ast /usr/jim
16 81 40
mail games test
(a)
31 70 59 38
bin memo f.c. prog1
/usr/ast /usr/jim
16 81 40 70
mail games test note
(b)
31 70 59 38
bin memo f.c. prog1
Figur 21: To kataloger før og etter opprettelsen av lenken “note”
2222222222222222222222222222222222222222222222222222222222222222222222222222222222222UNIX Win32 Description2222222222222222222222222222222222222222222222222222222222222222222222222222222222222
fork CreateProcess Create a new process2222222222222222222222222222222222222222222222222222222222222222222222222222222222222waitpid WaitForSingleObject Can wait for a process to exit2222222222222222222222222222222222222222222222222222222222222222222222222222222222222execve (none) CreateProcess = fork + execve2222222222222222222222222222222222222222222222222222222222222222222222222222222222222exit ExitProcess Terminate execution2222222222222222222222222222222222222222222222222222222222222222222222222222222222222open CreateFile Create a file or open an existing file2222222222222222222222222222222222222222222222222222222222222222222222222222222222222close CloseHandle Close a file2222222222222222222222222222222222222222222222222222222222222222222222222222222222222read ReadFile Read data from a file2222222222222222222222222222222222222222222222222222222222222222222222222222222222222write WriteFile Write data to a file2222222222222222222222222222222222222222222222222222222222222222222222222222222222222lseek SetFilePointer Move the file pointer2222222222222222222222222222222222222222222222222222222222222222222222222222222222222stat GetFileAttributesEx Get various file attributes2222222222222222222222222222222222222222222222222222222222222222222222222222222222222mkdir CreateDirectory Create a new directory2222222222222222222222222222222222222222222222222222222222222222222222222222222222222rmdir RemoveDirectory Remove an empty directory2222222222222222222222222222222222222222222222222222222222222222222222222222222222222link (none) Win32 does not support links2222222222222222222222222222222222222222222222222222222222222222222222222222222222222unlink DeleteFile Destroy an existing file2222222222222222222222222222222222222222222222222222222222222222222222222222222222222mount (none) Win32 does not support mount2222222222222222222222222222222222222222222222222222222222222222222222222222222222222umount (none) Win32 does not support mount2222222222222222222222222222222222222222222222222222222222222222222222222222222222222chdir SetCurrentDirectory Change the current working directory2222222222222222222222222222222222222222222222222222222222222222222222222222222222222chmod (none) Win32 does not support security (although NT does)2222222222222222222222222222222222222222222222222222222222222222222222222222222222222kill (none) Win32 does not support signals2222222222222222222222222222222222222222222222222222222222222222222222222222222222222time GetLocalTime Get the current time22222222222222222222222222222222222222222222222222222222222222222222222222222222222221111111111111111111111111111
1111111111111111111111111111
1111111111111111111111111111
1111111111111111111111111111
Figur 22: Sammenligning mellom Unix og Win32 API systemkall
19
Main procedure
Service procedures
Utility procedures
Figur 23: En enkel strukturmodell for et monolittisk system
22222222222222222222222222222222222222222222222222Layer Function22222222222222222222222222222222222222222222222222
5 The operator222222222222222222222222222222222222222222222222224 User programs222222222222222222222222222222222222222222222222223 Input/output management222222222222222222222222222222222222222222222222222 Operator-process communication222222222222222222222222222222222222222222222222221 Memory and drum management222222222222222222222222222222222222222222222222220 Processor allocation and multiprogramming2222222222222222222222222222222222222222222222222211
11111111
1111111111
1111111111
Figur 24: Struktur for THE OS
6 OS struktur
Forskjellige operativsystemer er strukturert på forskjellige måter. Monolittiske OS(fig. 23) består stort sett av en eneste stor kjerne (med hjelperutiner). Lagdelte ope-rativsystemer (som THE OS i fig. 24) har klart definerte lag, hvor bl.a. privilegienivåavhenger av hvilet lag man befinner seg på.
En annen løsning er bruk av virtuelle maskiner, som i IBM VM/370 med Conver-sational Monitor System (CMS) illustrert i fig. 25. Her får hver bruker en virtuellVM/370 maskin, dvs. det ser ut for brukeren som om han har hele maskinen for segselv, og kan gjøre alle systemkall og minnedisposisjoner etter eget forgodtbefinnen-de. Imidlertid vil et hvert forsøk på å utføre slke operasjoner føre til en overgang(trap) til kjernen, hvor det sentrale VM/370 operativsystemet allokerer ressurser ogvurderer gyldighet av operasjoner.
Enkelte mikro-kjerne-arkitekturer bruker klient/tjener-mekanismer for å holde mestmulig funksjonalitet utenfor kjernen. Her vil systemkall for det meste bare bli videre-
20
I/O instructions here
Trap here
Trap here
System calls here
Virtual 370s
CMS CMS CMS
VM/370
370 Bare hardware
Figur 25: Struktur for VM/370 med CMS
Client process
Client process
Process server
Terminal server
File server
Memory server
Microkernel
User mode
Kernel mode
Client obtains service by sending messages to server processes
Figur 26: Klient/tjener-modellen for en mikrokjernearkitektur
formidlet til hånderingsrutiner i brukermodus, som illustrert i fig. 26. I distribuertesystemer er dette mer vanlig, og her vil det i enkelte tilfeller være slik at brukerenikke er klar over at tjeneren som f.eks. leverer data befinner seg på en annen maskin,som vist på fig. 27.
Machine 1 Machine 2 Machine 3 Machine 4
Client
Kernel
File server
Kernel
Process server
Kernel
Terminal server
Kernel
Message from client to server
Network
Figur 27: Klient/tjener-modellen for et distribuert system
21
7 Litt metrikk til slutt
Både bit og byte forkortes med sin forbokstav, men for å skille dem fra hverandre
brukes liten b for bit og STOR B for byte.
De metriske betegnelsene kilo, mega, giga, terra, etc. brukes ogsåinnen dataverdenen, men for sikkerhets skyld får de litt forskjellig
betydning avhengig om vi snakker om hastigheter (f.eks. overfø-ringsrater) eller lagringsplass (f.eks. størrelse på RAM-brikker).
Hastigheter angis f.eks. i Mb per sekund, og i denne sammenhen-
gen betyr Mega 106, dvs. 1 Mb/s = 1 000 000 bit per sekund.
Lagringsplass angis f.eks. i MB, men her betyr Mega imidlertid
220, noe som medfører at 1 MB = 1 048 576 byte.
22
A Ordliste
Her følger en stadig voksende alfabetisk liste over mer eller mindre
egendefinerte norske ord på velkjente engelske begreper.
agent-annonsering Agent Advertisement
agentoppdagelse Agent Discovery
applikasjonsnivå portner Application Level Gateway
avbruddshåndterer interrupt handler
besøksagent Foreign Agent
bit-kart bitmap
buffer-oversvømmelse buffer overflow eller stack overflow
bytte-minne swap space eller bare swap
dataflyt flow
diskresjonær aksesskontroll discretionary access control, DAC
dobbelstakk dual stack
endesystem host eller end system
enhetsdriver device driver
fil-håndtak file handle
flytmerke flow label
fordeling scheduling
forhåndslesing read-ahead
forskyvning offset
grensesnitt interface (som i network interface card)
hjemme-agent home agent
hurtiglager cache
inndata input
23
kompis buddy
kritisk segment critical section
nabo-oppdagelse Neighbor Discovery
nettverksadresseoversetting Network Address Translation
nisje - slot
node - site (avhengig av sammenheng)
planlegger scheduler
planlegging scheduling
rekkevidde scope
ressursfordeling scheduling
ruter router
ruter-annonsering router advertisement
ruter-forespørsel router solicitation
ruting routing
sammenhengende contiguous (burde kanskje vært “tilstøten-
de”)
selvtilstrekkelig self contained
skank trailer
skolt header
stamnett backbone
sted site (avhengig av sammenheng)
strøm stream
svitsjing switching
sykel cycle
systemkall-grensesnitt Application Program Interface
sømløs seamless
24
tilstandsbasert stateful
tjener server
tjenestekvalitet Quality of Service
vandring roaming
Referanser
[Tan01a] Andrew S. Tanenbaum. Modern Operating Systems.Prentice-Hall, 2nd edition, 2001.
[Tan01b] Andrew S. Tanenbaum. MOS sli-
des. http://www.prenhall.com/divisions-/esm/app/author_tanenbaum/custom/mos2e/, 2001.
25