Introduksjon til operativsystemer

Transkript

1 Introduksjon til operativsystemer Martin Gilje Jaatun 30. april 2007 Sammendrag Dette dokumentet er et forsøk på å formidle noen velmenende formuleringer om operativsystemet, 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 norske uttrykk er derfor forsøkt brukt gjennomgående. Imidlertid er etablerte engelske forkortelser beholdt. Innhold Innledning 3 1 Historisk tilbakeblikk Generasjoner av datamaskiner Satsvise systemer Multiprogrammering Ikke bare Arnardo og Merano 6 3 Noen sentrale maskinvarebegreper Henry Ford hadde vært stolt Minnehierarki Harddisk Deling av programkode Avbrudd Gode busser Operativsystemkonsepter Prosesser Vranglås Filer

2 5 Systemkall Prosessadministrasjon Fil- og katalogadministrasjon Unix vs. Win OS struktur 20 7 Litt metrikk til slutt 22 A Ordliste 23 Figurer 1 Hva består et datamaskinsystem av? Operasjoner involvert i en satsvis kjøring av et program Struktur på en typisk FMS-jobb Multiprogrammering: Tre jobber i minnet på en gang Grovskisse over komponenter i en enkel PC (a) En tre-trinns rørledning (b) En superscalar CPU Typisk minnehierarki Innvendig struktur på en harddisk Effekten av å dele programkode mellom flere prosesser Starting av en I/O-enhet og mottak av avbrudd, og hvordan dette ser ut for programmet Blokkskjema for en moderne Pentium PC Et prosesstre En potensiell vranglås og en manifest vranglås Et filsystem for en høgskoleavdeling Montering av filsystem To prosesser koblet sammen med et rør steg for å utføre systemkallet read(fd,buffer,nbytes) Et utvalg av de viktigste POSIX systemkallene Et minimalistisk skall De tre segmentene assosiert med en prosess To kataloger før og etter opprettelsen av lenken note Sammenligning mellom Unix og Win32 API systemkall En enkel strukturmodell for et monolittisk system Struktur for THE OS Struktur for VM/370 med CMS Klient/tjener-modellen for en mikrokjernearkitektur Klient/tjener-modellen for et distribuert system

3 Innledning Figur 1: Hva består et datamaskinsystem av? Som det fremgår av fig. 1, består et datamaskinsystem av maskinvare, systemprogramvare og applikasjonsprogramvare. Maskinvaren omfatter de fysiske enhetene (mikroprosessor, harddisk, RAM-brikker, etc.), men også mikroarkitektur (f.eks. i en 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) et reservasjonssystem for et flyselskap. Systemprogramvare er kanskje den mest vage av de tre hovedkomponentene. Selv om kompilatorer, editorer og skall (command interpreters) strengt tatt ikke er en del av operativsystemet, er de ofte så tett integrert med dette at brukeren oppfatter dem som 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 likevel ha ganske tett interaksjon med det. Av denne grunn vil dette faget også ta for seg en del praktisk bruk av slike systemprogrammer, spesielt i konteksten scriptprogrammering og bruk av systemkall. Hva er så egentlig et operativsystem? Vår venn [Tan01a] presenterer to alternative 3

4 abstraksjoner som utfyller hverandre: Et OS er en utvidet datamaskin, eller et OS er en ressursadministrator. I forskjellige sammenhenger vil vi se at enten den ene eller den andre abstraksjonen føles mest riktig. Det at vi ser på operativsystemet som en utvidet datamaskin betyr at det skjuler de skitne detaljene i alt arbeidet som må gjøres når datamaskinen skal utføre sine oppgaver. Operativsystemet presenterer en virtuell maskin på et høyere abstraksjonsnivå for brukeren, noe som gjør systemet enklere å bruke (på samme måte som at de fleste av oss synes det er enklere å programmere i et høynivå programmeringssprå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 datamaskin samtidig, er det noen som må sørge for at dette skjer i henhold til nærmere definerte regler. Ofte vil man forsøke å gjøre dette så rettferdig som mulig, dvs. at hvert 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 er relevant (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 operativsystem i det hele tatt, og da operativsystemene dukket opp, hadde de først betydelig mindre funskjonalitet enn det vi forventer i dag. 1.1 Generasjoner av datamaskiner Boka deler datamaskin-historien inn i fire generasjoner: i dag Første generasjon kan som nevnt knapt sies å ha hatt operativsystemer, og var karakterisert ved bruk av radio-rør (vacum tubes) og programmering ved hjelp av sammenkobling av ledninger på såkalte plugge-brett (plug boards) tilsvarende et gammelt manuelt sentralbord. Andre generasjon tok i bruk transistorer og satsvise system, mens tredje generasjon var karakterisert ved integrerte kretser og multiprogrammering. Den fjerde generasjonen startet med lanseringen av IBMs Personal Computer, og verden har som kjent ikke vært den samme siden. 4

5 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 et satsvis 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 en liten datamaskin (kalt 1401 i figuren), hvor hullkortene ble lest, og informasjonen skrevet over på magnetisk tape. Denne tapen ble så båret fra 1401-maskinen til maskinen, hvor programmet ble lest inn og de faktiske beregningene i programmet ble utført. Resultatet ble skrevet til en nye tape, som deretter måtte flyttes til en nye 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) til man fikk resultatet (etter (f)); ettersom datamaskiner var sinnsykt dyre, var det vanligvis en lang kø med jobber som skulle utføres, slik at arbeidsmønsteret for en satsvis programmerer gjerne ble slik man nå forbinder med installering av Linux: Lever jobb spis lunsj (evt. også middag) sjekk resultat. Dersom det var en liten feil i programmet, medførte det (da som nå) at hele greia kræsjet, men til forskjell fra i dag medførte dette igjen timevis med tapt arbeidstid. De første satsvise systemene kunne bare programmeres i maskinspråk, men etter hvert fikk man mer høynivå programmeringsspråk som FORTRAN. På dette tidspunktet hadde man fremdeles bare veldig enkle operativsystemer som Fortran Monitor System (FMS), som ikke hadde stort større funksjonalitet enn å lese inn programkoden, kjøre FORTRAN-kompilatoren, og kjøre det resulterende programmet med da vedlagte data. Hvordan hullkortene i en slik jobb kunne struktureres er illustrert i fig. 3. 5

6 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 gangen. Multiprogrammeringen som ble introdusert i tredje generasjon gjorde det mulig for en datamaskin å ha flere forskjellige programmer lastet inn i minnet samtidig i tillegg til selve operativsystemet. Dette vises i fig Ikke bare Arnardo og Merano I dag har vi det reneste sirkus 1 av operativsystemer å forholde oss til. Eksempler nevnes i fleng: Stormaskin (mainframe) OS Tjener (server) OS Multiprosessor OS OS for personlige datamaskiner OS for håndholdte datamaskiner (PDA) Sanntids OS 1 Som illustrert på forsiden av [Tan01a] til tross for at Andy selv kaller det the operating system zoo 6

7 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 vil vi bevege oss på det generelle plan. 3 Noen sentrale maskinvarebegreper I dette avsnittet presenterer vi noen sentrale maskinvarebegreper som forhåpentligvis burde være kjent for de fleste. I fig. 5 vises det en forenklet oversikt over typiske komponenter i en personlig datamaskin. Mikroprosessoren (Central Processing Unit CPU) er datamaskinens hjerne, 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. Brukeren skriver sine kommandoer til datamaskinen på tastaturet (og i våre dager har man dessuten vanligvis en mus), og flytter på programmer og data vha. flyttbare media som 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ørselen av 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

8 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 (pipelining), er at når første instruksjon er hentet, og sendt videre til dekoding, kan man gå ut og hente neste instruksjon, uten å vente på at den første instruksjonen er ferdig 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 spesialiserte) utførselsenheter. For enkelte applikasjoner kan dette gi en veldig stor grad av parallellitet, med tilsvarende ytelsesforbedring. 8

9 3.2 Minnehierarki Figur 7: Typisk minnehierarki Prisen på minne er (grovt sett) proporsjonal med hastigheten, og i praksis betyr dette størrelsen (som man har råd til) av hver minnetype er omvendt proporsjonal med hastigheten. Den aller raskeste minnetypen er registrene som er en integrert på selve mikroprosessoren, men disse utgjør totalt mindre enn 1kB lagringsplass. Deretter kommer hurtiglager (cache) på rundt 1 MB, primærlager (RAM) rundt 1GB, sekundærlager (harddisk) på rundt 200 GB. Installasjoner med store dataog/eller sikkerhetskopieringsbehov har dessuten tertiærlager (tape) med terabyte på 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 prosess har 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 hvis flere 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 og limit-2 angir dataområdet. Når operativsystemet bytter mellom prosess 1 og prosess 9

10 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-2 endres til å peke på dataområdet til prosess Avbrudd I mange tilfeller vil aksess til I/O-enheter være avbruddsdrevet, dvs. at prosessoren vil 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 i fig. 10 a) ) generere et avbrudd som håndteres av avbruddshåntereren, og som igjen aktiverer CPU-ens avbruddslinje. 3.6 Gode busser En moderne Pentium-basert PC har et utall forskjelige busser på hovedkortet, som illustrert på fig Operativsystemkonsepter Bortsett fra at dette er tittelen på en konkurrerende lærebok, dekker dette uttrykket en del fundamentale begreper som man må mestre dersom man skal ha noe håp om å forstå de mest vesentlige aspekter ved operativsystemfaget. 10

11 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 har A opprettet to barneprosesser B og C, mens B igjen har opprettet tre barneprosesser D, 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 en klassisk vranglås i den virkelige verden kan oppstå i et veikryss med norsk høyreregel og overdrevent høflige sjåfører har man i praksis en vranglås allerede i første del 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

12 Figur 10: Starting av en I/O-enhet og mottak av avbrudd, og hvordan dette ser ut for programmet 12

13 Cache bus Local bus Memory bus Level 2 cache CPU PCI bridge Main memory PCI bus SCSI USB ISA bridge IDE disk Graphics adaptor Available PCI slot Mouse Key- board ISA bus Mon- itor Modem Sound card Printer Available ISA slot Figur 11: Blokkskjema for en moderne Pentium PC A B C D E F Figur 12: Et prosesstre 13

14 (a) (b) Figur 13: En potensiell vranglås og en manifest vranglås Root directory Students Faculty Robbert Matty Leo Prof.Brown Prof.Green Prof.White Courses Papers Grants Committees CS101 CS105 Files SOSP COST-11 Figur 14: Et filsystem for en høgskoleavdeling 14

15 Root Floppy a b x y a b c d c d x y (a) (b) Figur 15: Montering av filsystem Process A Pipe Process 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 i fig. 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 omfattes av fil-sematikken. F.eks. innen et C-program vil man ofte ha variable som ligner på fildeskriptorer som behandles helt analogt til filer (skriving, lesing, etc.), men som egentlig er noe annet. Et eksempel på dette er rør -konseptet (pipe), illustrert på fig. 16. Dersom to prosesser ønsker å kommunisere med hverandre, kan dette gjøres via et rør, som må være satt opp på forhånd. Vanligvis gjøres dette ved at en mor-prossess oppretter røret før den oppretter barneprosessen med fork(). Når barneprosessen starter opp, har den en kopi av alle morens variable inkludert røret, som den da kan begynne å bruke. 5 Systemkall Grensesnittet mellom operativsystemet og brukerprogram er definert ved et sett av systemkall. I fig. 17 vises det hvilke trinn man må gå gjennom for å lese nbytes byte fra filen som pekes på av fildeskriptoren fd inn i bufferet buffer (dvs. utføre systemkallet read(fd,buffer,nbytes)): 1. nbytes dyttes på stakken 15

16 Address 0xFFFFFFFF Return to caller Trap to the kernel 5 Put code for read in register Library procedure read 4 10 User space Increment SP Call read Push fd Push &buffer Push nbytes 11 User program calling read 6 9 Kernel space (Operating system) Dispatch 7 8 Sys call handler 0 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 (system call 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 til tilstanden før nbytes etc. ble stappet inn i den. Fig. 18 viser de viktisgste POSIX systemkallene, som både støttes av Unix, Linux og (i større eller mindre grad) Windows 2000/XP. 16

17 Process management Call Description pid = fork( ) Create a child process identical to the parent pid = waitpid(pid, &statloc, options) Wait for a child to terminate s = execve(name, argv, environp) Replace a process core image exit(status) Terminate process execution and return status File management Call Description fd = open(file, how,...) Open a file for reading, writing or both s = close(fd) Close an open file n = read(fd, buffer, nbytes) Read data from a file into a buffer n = write(fd, buffer, nbytes) Write data from a buffer into a file position = lseek(fd, offset, whence) Move the file pointer s = stat(name, &buf) Get a file s status information Directory and file system management Call Description s = mkdir(name, mode) Create a new directory s = rmdir(name) Remove an empty directory s = link(name1, name2) Create a new entry, name2, pointing to name1 s = unlink(name) Remove a directory entry s = mount(special, name, flag) Mount a file system s = umount(special) Unmount a file system Miscellaneous Call Description s = chdir(dirname) Change the working directory s = chmod(name, mode) Change a file s protection bits s = kill(pid, signal) Send a signal to a process seconds = time(&seconds) Get the elapsed time since Jan. 1, 1970 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

18 Stack Address (hex) FFFF Gap Data Text 0000 Figur 20: De tre segmentene assosiert med en prosess 5.1 Prosessadministrasjon Generel anses prosesser for å ha tre segmenter: Tekst-segmentet inneholder programkoden, data-segmentet (også kjent som heap) inneholder variablene, og stakksegmentet (pussig nok) stakken. Disse segmentene trenger ikke være allokert kontinuerlig (som indikert i fig. 9), men det er vanlig at stakk- og data-segmentet henger sammen med en blokk med ledig plass i mellom, slik at de kan vokse mot hverandre. Dette er illustrert i fig Fil- og katalogadministrasjon Unix har konseptet harde og myke lenker (links). I fig. 21 vises effekten av å lage en hard lenke note til katalogen /usr/jim/memo fra katalogen /usr/ast. Vi ser at /usr/jim/memo har samme ID som /usr/ast/note, noe som betyr at de er to likeverdige 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 Win32 API. Her er det viktig å merke seg at forfatteren begrenser seg til det som støttes av f.eks. Windows 98, og ikke skjeler til f.eks. Windows Dette vil vi imidlertid komme tilbake til mot slutten av boka. 18

19 /usr/ast /usr/jim /usr/ast /usr/jim mail games test bin memo f.c. prog mail games test note bin memo f.c. prog1 (a) (b) Figur 21: To kataloger før og etter opprettelsen av lenken note UNIX Win32 Description fork CreateProcess Create a new process waitpid WaitForSingleObject Can wait for a process to exit execve (none) CreateProcess = fork + execve exit ExitProcess Terminate execution open CreateFile Create a file or open an existing file close CloseHandle Close a file read ReadFile Read data from a file write WriteFile Write data to a file lseek SetFilePointer Move the file pointer stat GetFileAttributesEx Get various file attributes mkdir CreateDirectory Create a new directory rmdir RemoveDirectory Remove an empty directory link (none) Win32 does not support links unlink DeleteFile Destroy an existing file mount (none) Win32 does not support mount umount (none) Win32 does not support mount chdir SetCurrentDirectory Change the current working directory chmod (none) Win32 does not support security (although NT does) kill (none) Win32 does not support signals time GetLocalTime Get the current time Figur 22: Sammenligning mellom Unix og Win32 API systemkall 19

20 Main procedure Service procedures Utility procedures Figur 23: En enkel strukturmodell for et monolittisk system Layer Function 5 The operator 4 User programs 3 Input/output management 2 Operator-process communication 1 Memory and drum management 0 Processor allocation and multiprogramming 6 OS struktur Figur 24: Struktur for THE OS Forskjellige operativsystemer er strukturert på forskjellige måter. Monolittiske OS (fig. 23) består stort sett av en eneste stor kjerne (med hjelperutiner). Lagdelte operativsystemer (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 Conversational Monitor System (CMS) illustrert i fig. 25. Her får hver bruker en virtuell VM/370 maskin, dvs. det ser ut for brukeren som om han har hele maskinen for seg selv, og kan gjøre alle systemkall og minnedisposisjoner etter eget forgodtbefinnende. 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 og vurderer gyldighet av operasjoner. Enkelte mikro-kjerne-arkitekturer bruker klient/tjener-mekanismer for å holde mest mulig funksjonalitet utenfor kjernen. Her vil systemkall for det meste bare bli videre- 20

21 Virtual 370s I/O instructions here Trap here CMS CMS CMS VM/ Bare hardware System calls here Trap here Figur 25: Struktur for VM/370 med CMS Client process Client process Process server Terminal server Microkernel File server Memory server 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 distribuerte systemer er dette mer vanlig, og her vil det i enkelte tilfeller være slik at brukeren ikke 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 File server Process server Terminal server Kernel Kernel Kernel Kernel Message from client to server Network Figur 27: Klient/tjener-modellen for et distribuert system 21

22 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 sammenhengen betyr Mega 10 6, dvs. 1 Mb/s = bit per sekund. Lagringsplass angis f.eks. i MB, men her betyr Mega imidlertid 2 20, noe som medfører at 1 MB = byte. 22

23 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

24 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øtende ) 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

25 tilstandsbasert stateful tjener server tjenestekvalitet Quality of Service vandring roaming Referanser [Tan01a] Andrew S. Tanenbaum. Modern Operating Systems. Prentice-Hall, 2nd edition, [Tan01b] Andrew S. Tanenbaum. MOS slides. /esm/app/author_tanenbaum/custom/mos2e/,