![[illustrasjon av arbeidssyklusen]](http://rhiann.nvg.ntnu.no:8080/mnfit222/OE/O1/arbeidssyklusen.gif)
Illustrasjonen er hentet fra permen.
Enklest sett er operativsystemet bindeleddet mellom maskinvaren og programvaren i datamaskinen. Operativsystemet kontrollerer ressursene, såsom filsystem, prosessoren, minnet og inn/ut-enheter, og lar programmene få tilgang til disse gjennom systemkall.
Operativsystemet fordeler ressursene mellom prosessene som kjører til et hvert tidspunkt, slik at konflikter ikke oppstår, herunder også evt. flerkjøring, dvs. fordeling av prosessorkraften mellom prosesser. Som en del av ressursfordelingen inngår også administrering av minnet. Operativsystemet gjør sitt for at hver prosess har nok minne når de kjører, når en prosess ligger i kø kan dens minnedata legges på ytre lager for å gi plass til en annen prosess.
Operativsystemet kommer gjerne med et grensesnitt mot brukeren, i form av et skall for styring av prosesser, organisering av filstruktur og rettigheter og generell konfigurering. Noen operativsystemer har implementert skallet som et grafisk grensesnitt i tillegg til et tekstbasert.
For å sikre data og programflyt bør operativsystemet ha kontroll over minnet slik at ikke en prosess skriver over en annen prosess minneområde og ordne opp hvis noe går galt, fx. frigjøre minneområde, åpne filer, etc. hvis et program går i stå.
Referanser: Tanenbaum, Staupe
Operativsystemet gir programmer en enklere måte å kommunisere med maskinvaren, det kan skjule maskininstrukser som er tungvinte og unødvendige for den jevne programmerer å sysle med til fordel for enkle systemkall.
Et filsystem gir programmene en enkel måte å lagre og hente data, og bør samtidig være oversiktlig og strukturert. Operativsystemet gir programvaren et filsystem, og tar seg av de lavereliggende fysiske funksjonene for å lagre data, som hvilken enhet dataene skal ligge på, og hvor på enheten.
Hver instans av et program som kjører kalles en prosess. Operativsystemet gir et program muligheten til å starte nye prosesser, slik at andre programmer kan bli startet eller rett og slett en ny kopi av programmet selv. Det sistnevnte er sjelden nyttig med mindre operativsystemet har flerkjøring.
Flerkjøring vil si at operativsystemet lar en prosess kjøre i et begrenset tidsrom, og deretter la en annen prosess kjøre, og på den måten kan flere prosesser kjøre "samtidig". Det er mange forskjellige måter å fordele prosessortiden på, det kan variere mellom arkitekturer, operativsystem og oppsett.
Operativsystemet bør ofte ha et grensesnitt mot brukeren, enten i form av et skall eller et grafisk miljø. Grensesnittet lar brukeren organisere filer, kjøre og styre prosesser og kontrollere operativsystemet, i den grad brukeren er innvilget tilgang.
Referanser: Tanenbaum, Staupe
Vi antar at oppgaven spør etter lenking av filer. Vi velger å ta for oss lenking i UNIX.
I de fleste filsystemene som benyttes i UNIX-systemer finnes det to typer lenking, 'harde' lenker og symbolske lenker.
En hard lenke er et navn for en inode, dvs. et kataloginnslag som referer til inoden. En inode har pekere til hvor i filsystemet blokkene som utgjør selve filen befinner seg og inneholder samtidig informasjon om eierskap, rettigheter og viktige datoer i filens liv.
Man kan ha flere slike navn
til samme inode, slik at en og samme fil kan befinne seg flere steder i
filsystemet samtidig, dog må alle filoppføringene være i samme filsystem.
(les: partisjon). En inode blir ikke slettet før det ikke lenger
er noen navn som peker til den, slik at for å frigjøre plassen en
fil opptar må alle de harde lenkene som peker til filen slettes. Man
kan ikke selv hardlenke kataloger, men katalogoppføringene
. og .. er hardlenker til henholdsvis samme og
forrige katalog.
En symbolsk lenke er en referanse til en sti i filsystemet. Lenken kan være relativ eller absolutt. Når et program bruker lenken vil kjernen slå opp i filsystemet og bruke katalogoppføringen lenken peker til istedet.
Fordelen med lenker generelt sett er at en fil kan være representert flere steder i filsystemet, noe som samtidig kan virke forvirrende for en bruker. Hvis en fil blir endret et sted blir også 'en annen fil' endret. Harde lenker virker bare innenfor et enkelt filsystem. Symbolske lenker er egne pekerfiler, mens harde lenker er likverdige med andre katalogoppføring for filen.
Referanser: ln(1), link(2), fileutils/src/ln.c, linux/fs/ext2/nameic.2
Vi antar at oppgaven spør etter lenking av biblioteker.
Når man kompilerer et program er det vanlig å bruke funksjoner ifra eksterne biblioteker. Disse kan linkes inn i binærfilen (den kjørbare filen) på forskjellige måter.
Statisk linking vil si at den ferdigkompilerte maskinkoden for funksjonene blir inkludert i binærfilen. Dette gjør at binærfilen blir stor, og om man har flere binærfiler som bruker samme funksjoner vil man sløse med lagerplass både i ytre og indre lager. Fordelen med statisk linking er at man kan være helt sikker på at biblioteket er tilgjengelig og hvilken versjon dette er, og distribuere binæren alene.
Dynamisk linking vil si at det blir inkludert referanser til eksterne biblioteker, slik at ved kjøring av binæren må de eksterne bibliotekene finnes på systemet. I samarbeid med operativsystemet kan da flere forskjellige prosesser dele felles biblioteker. Ulempen blir altså at man må sørge for at bibliotekene er i systemet, og det reiser seg også en problematikk ved å ha flere versjoner av samme bibliotek installert.
Referanser: ld(1), ldconfig(8)
Skallet er brukerens måte å kommunisere med operativsystemet. Gjennom kommandoer eller navigering i grafiske systemer kan brukeren instruere operativsystemet til å kopiere og slette filer, starte og avslutte prosesser.
Det finnes mange varianter av skall, de vanligste variantene er
tekstbaserte eller vindusbaserte. I et tekstbasert skall bruker
man kommandoer til å angi hva man vil gjøre og hvordan. Kommandoene
har ikke nødvendigvis logiske navn i seg selv, i UNIX er fx.
kommandoen for å slette filen 'test.txt' rm test.txt. 'rm'
står her for 'remove'. Et slikt tekstbasert skall gir likevel
brukeren en styrke til å gjøre det han vil når han kjenner
kommandoene, men vil altså ha en høy terskel for nybegynnere.
Styrken til et tekstbasert skall er at man kan kombinere kommandoer,
fx. ved piping, hvor man kan videresende utdataene fra en kommando
som en annen kommandos inndata, fx. ls | grep -v txt vil
returnere alle filnavnene som ikke har 'txt' i seg. Man kan
lage samlinger av kommandoer i såkalte skript eller satsvise filer
og dermed effektivisere bruken.
Vindusbaserte skall er ofte basert på en slags objektorientering, gjerne med et skrivebordkonsept. Kataloger i filsystemet blir presentert som mapper, og man kan klikke og dra filer mellom mappene. Datafilene er assosiert med programmer, slik at man kan arbeide med filene direkte uten å tenke på hvilket program de hører hjemme i.
Vindusgrensesnittet har som regel en lav terskel, slik at nybegynnere lett kan få en forståelse for bruken. Grensesnittet har også strukturer for å gi et helhetlig inntrykk, slik at man føler man arbeider i et homogent miljø.
Muligheten for å effektivisere arbeidet i vindusbaserte skall er som regel liten, man må navigere manuelt med pekerredskap eller tastetrykk. Dersom operativsystemet har en underliggende tekstbasert skall har det lite å si, men noen operativsystemer har fokusert så mye på det grafiske grensesnittet at det tekstbaserte skallet ikke lenger har alle mulighetene som det grafiske.
Referanser: ()
På denne tiden begynte man å lykkes med digitale datamaskiner. Programmering ble gjort i ren maskinkode, ofte ved å koble sammen ledninger. Programmeringsspråk eksisterte ikke.
Maskinene, som bestod av radiorør, var svært upålitelige, og bruktes derfor mest av de samme forskerne som utviklet maskinene.
Programmererne satte av tid ved maskinen, og hadde den for seg selv i dette tidsrommet - koblet den sammen og prøvde å få gjort sine beregninger. Mulighetene for å gjøre små endringer og prøve på ny var store så lenge man var innenfor tiden som var satt av.
Etterhvert begynte man også med hullkort, uten at det forandret det noe særlig.
Transistoren gjorde datamaskinen til et pålitelig og kommersielt fornuftig produkt. Dette gjorde at maskinens utviklere, driftere, og brukere for første gang ble skilt fra hverandre. Programmene ble skrevet i assembler eller Fortran, punchet på hullkort, og kjørt gjennom maskinen. Resultatet ble så skrevet ut. Dette medførte mye flytting av kort, og vandring rundt på maskinrommet - noe som sløste med tid på veldig dyre maskiner.
Løsningen ble å laste mange kort inn på tape i på en billig maskin, for så å ta denne tapen med til den dyre og raske maskinen. Resultatene fra kjøringen ble også skrevet ut på tape, som så ble tatt med til en billig maskin. Denne løsning ble kalt batch-systemer. Input-tapen var inndelt etter et spesielt jobbkontrolspråk, som operativsystemet tolket. Operativsystemet kunne være FMS (Fortran Monitor System) og IBSYS, IBMs operativsystem for 7094.
På begynnelsen av 60-tallet hadde de fleste datamaskinleverandører 2 produktlinjer - store beregningsmaskiner, som IBM 7094, og tegnbaserte, kommersielle maskiner som 1401. Dette gav problemer - både ved oppskalerings og ved utvikling og vedlikehold. Derfor introduserte IBM System/360 - en hel serie med maskiner i alle kategorier som kjørte samme operativsystem og samme programmer. Systemet var ekstremt stort og komplekst, og het OS/360. Dette introduserte også multiprogrammering - operativsystemet muliggjorde kjøring av flere programmer samtidig, slik at man f.eks. kunne lese inn data til et program mens et annet ventet på I/O - dette var særlig relevant for næringslivet, der applikasjonene svært ofte var I/O-bundne (lesing/skriving til databaser osv.)
Spooling ble også introduserte - dette gjorde det mulig å lese hullkort inn på disk direkte, og gjorde dermed spesialiserte kort->tape maskiner overflødige.
Dette medførte et problem - rask endring og kjøring av programmer i debuggingsfasen ble umulig, ettersom systemene i realiteten fortsatt var batch-systemer måtte man vente lenge for å få kjørt en jobb. Løsningen på dette ble timesharing - mange brukere kunne da være logget inn på systemet og få hver sin del av CPU-tiden, dermed kunne alle få følelsen av at de hadde maskinen for seg selv.
Dette ble videreført med operativsystemet MULTICS, et svært komplekst operativsystem som aldri ble noen stor kommersiell suksess. Likevel fikk det stor innflydelse på senere systemer - UNIX ble utviklet som en nedstrippet MULTICS, og har fått stor suksess, først på DECs PDP-serie, og senere på andre arkitekturer.
PCen og andre hjemmedatamaskiner introduserte brukervennlige programmer - etterhvert også vindussystemer. De dominerende operativsystemene i denne perioden var MS-DOS og UNIX, MS-DOS på hjemmedatamaskiner, UNIX på arbeidsstasjoner og servere. Den store endringen var at datamaskiner nå var noe som stod på pulten til helt vanlige mennesker og brukere - altså var man gått bort fra store servere og dumme terminaler. Etterhvert innså man at en del funksjonalitet hadde gått tapt fra stormaskinene, og lokalnettverk ble vanlige - dette medførte egne nettverksoperativsystemer som sørget for fil- og skriverdeling m.v. UNIX hadde slik funksjonalitet, og denne ble utvidet, mens nye systemer som Novell Netware og MS/IBM Lan Manager dukket opp.
På slutten av 80-tallet begynte vindussystemene å vokse frem, operativssystemene ble nå utvidet til å også innholde et grafisk miljø (noen systemer hadde hatt dette lenge.) Eksempler på slike miljøer er Microsofts Windows og The X Window System fra MIT. Operativsystemene fikk også innebygget nettverks- og multimediafunksjonalitet, og PC-operativsystemene håndterte kommunikasjon mot hardware i mye større grad enn MSDOS, der hvert program ofte måtte ha sine egne løsninger for dette. Dette hadde også sammenheng med at ekte multitasking kom på vanlige PCer - man måtte da tenke mer slik som man alltid hadde gjort i "skikkelige" operativsystemer, med beskyttet minne osv slik at programmene ikke kunne ødelegge for hverandre. Distribuerte systemer er også i vinden, de dominerende operativsystemene kan knapt sies å være distribuerte, men trenden går i den retningen (X er et distribuert vindussystem.) En del av trenden er også at store servere og dumme terminaler er på vei inn igjen, om enn med grafiske skjermer. Nettverk, og da særlig internet, er det som driver utviklingen, som det heter i slagordet fra Sun Microsystems; "The Network is the Computer".
CPUen (Central Processing Unit) er en datamaskins hjerne, den bestemmer -hva- og -når- noe skal skje, og delegerer oppgaver til de andre delene i systemet. Minnehåndtering og integer-matematikk (altså heltallsmatematikk) står den for selv, mens f.eks flyttalls-matematikk og lav-nivå-kontroll av disk, buss-, grafikk- og io-enheter gjerne håndteres av andre.
ALUen (Algorithmetic and Logic Unit), også kjent som "møllen" (mill) er den delen av CPUen som tar seg av integer-matematikk, dvs. addisjon, subtraksjon, multiplikasjon, divisjon og modulus av heltall, og boolsk logikk (bitvis AND, OR, NOT etc.). Hva ALUen skal gjøre, hvor inputen kommer fra og hvor outputen skal, bestemmes av CPUen, og internt lagres dataene i flere registre, antallet avhenger av prosessortype. Når så en operasjon utføres på dataene i dataregistrene, legges gjerne svaret i egne svar-register, f.eks settes et flagg i et flagg-register. Flyttallsberegninger gjøres ofte av en egen enhet, FPUen (Floating-point Unit). Noen prosessorer benytter også ALUen til å beregne hvor neste adresse skal hentes.
Registre kan være spesielle eller generelle. De generelle kan benyttes til mellomlagring, mens andre register, flaggregister f.eks, gjerne påvirkes av hva som til en hver tid ligger i et spesiellt register.
Eksempel: I en 8086-prossesor vil 0x00 lagt i CX-registeret sette zero-flag. For å teste om en variabel er 0 i et assembler-program skrevet i TASM (som har makroer, navngitte variabler og navngitte hopp-posisjoner,) kan man f.eks gjøre:
MOV CX, [VAR]
JNZ ER_IKKE_NULL
JZ ER_NULL
Dvs. "kopier variabel inn i CX, sjekk om zero-flag er satt, hvis ikke hopp til ER_IKKE_NULL, ellers hopp til ER_NULL." CX brukes gjerne som generellt register, med tanke på at de gamle x86ene bare hadde 13 registre i alt...
Andre spesielle registre er instruksjonsregister, som inneholder instruksjonen som er under utførelse; instruksjonsadresseregister (PC, Program Counter), som inneholder adresse til neste instruksjon; og tilstandsregister (flaggregister), hvis bit-mønster viser tilstanden til de andre registrene. I TASM-eksempelet over samvirker et tilstandsregister, CX og PC idet J(N)Z er en hopp-instruksjon, og det er nettopp hopp- og kall-instruksjoner som kan sette PCen til noe annet enn resultatet av en ren inkrementering.
De nøyaktige stegene som må gjøres for å utføre en instruksjon er lagret i mikroinstruksjonsdelen.
Perm: s 80-81
I følge permen består en typisk buss av 32 adresselinjer, 32 datalinjer og mellom 20 til 30 styrelinjer. Utviklingen er i full gang mot 64-bits busser og operativsystem som fungerer på 64-bits prosessorer.
Hvorfor utvikling mot 64-bits? Vel, adresser/data sendes gjerne parallelt, altså det sendes et signal på hver av linjene. Dette gir en øvre grense i lagringskapasitet på 4 gigabits, dvs en halv gigabyte. Når det etterhvert blir vanligere å operere med bl.a lagringsenheter på flere GB må man enten "jukse" på ymse vis eller utvide kapasiteten på bussen, pluss at det i tillegg er mer effektivt når prosessoren ikke behøver konvertere signalene til og fra bussen til sitt interne format.
I en moderne bordmaskin (Intel-basert PC) er det separate databusser for prosessor/minne, prosessor/-cache (både intern rett på chipen og ekstern) prosessor/grafikk (AGP), og prosessor/generell buss (PCI og ISA). Hvis ikke prosessor/diskbuss (IDE eller SCSI, den siste brukes til atskillig mer enn bare disker) også er separat, kan disse kobles på via de generelle, med hastighetsreduksjoner til følge. Tidligere hadde ISA og PCI konkurrentene EISA (Enhanced ISA), VESA (Video Electronics Standards Association) og IBMs MCA (Micro Channel Architecture), men disse er nå så godt som borte, dog ryktes det at MCA er en kandidat for å bli brukt i PowerPC-maskiner.
Kommende buss-system er USB og FireWire
Linker:
Synonymer: primærminne, primærlager, indre lager, hurtiglager, kjernelager (core), hovedlager, hukommelse.
Synonymene sier mye om hva minnet brukes for. En grunn er at siden masselager (disker etc.) er treige, lønner det seg svært godt å flytte data og instruksjoner derfra før man begynner å gjøre noe som helst, man 'leser' derfor alt inn i minnet fra et annet medium før man begynner å bruke dataene til noe. Prosessoren jobber mot minnet, muligens via prosessorcacher.
Adressene til lagringsplassene i minnet består av bytes (en oktett, dvs 8 bits) eller ord (2, 4 eller 8 bytes). En i286 opererte med to-bytes ord, mens i386 bruker 4-bytes ord.
Dagens datamaskiner regner en byte som åtte bits, mens dette ikke nødvendigvis var tilfelle i gamle dager, for eksempel hadde en av PDP-modellene 9-bits "bytes", siden standard lagringsstørrelse var en longword på 36 bits.
Sentralenheter og IO-enheter aksesserer minnet via minne-styreenheter (MMU). Enheten som ønsker å aksessere minnet må først bli bussherre. Når dette har skjedd, kan enheten spørre MMUen om henholdsvis å få lese- eller skrivetilgang til minnet. MMUen oversetter spørrerens adresser fra og til de som minnet bruker, skriver data fra datalinjene til minnet, og dumper data andre veien når det skal leses.
Instruksjoner overføres til instruksjonsregisteret i styreenheten, data går til ALUen eller ytre enheter.
Illustrasjonen er hentet fra permen.
Først hentes neste instruksjon fra minnet og legges i instruksjonsregisteret (Pil og tekst til høyre på bildet). Så tolkes instruksjonen til noe maskina kan jobbe videre med, og de impliserte kretsene blir aktivert, operandadressene blir beregna før så operandene blir henta (nedre pil), deretter blir instruksjonen utført og resultatet om nødvendig lagra (venstre pil). Til slutt blir instruksjonsadresseregisteret oppdatert med adressen til neste instruksjon (øvre pil) og systemet starter på ny runde.