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