Real mode, monolitiska och mikrokÀrnor
För lÀnge, lÀnge sedan, som du sÀkert har sett pÄ bild, bestod datorer av stoora transistorer (vakumrör) och sladdar som gick hit och dit. De hade inget operativsystem, utan hur man kopplade sladdarna avgjorde vad datorerna utförde. Sen kom minidatorerna. En minidator Àr (mot vanlig tro) en dator som Àr ungefÀr stor som en bokhylla, fast lite djupare. Minidatorerna var mycket mer high-tech, och hade ett faktiskt maskinsprÄk. Olika bitar i minnet representerade olika instruktioner och sÄ vidare.
Fördelen med det systemet Àr att det nu gÄr att ladda in program externt. De tvÄ vanligaste metoderna var probably antingen genom strömbrytare (tÀnk Ätta strömbrytare för en octet, och sen en "spara"-switch för att spara octeten i minnet och gÄ vidare till nÀsta minnescell.) Eller, sÄ kunde man ladda in hÄlremsor. HÄlremsor Àr lite som hÄlkort, fast med en remsa. Ett hÄl stod för en binÀr etta, och inget hÄl stod för en binÀr nolla. Remsan var ungefÀr Ätta hÄl i bredd. Först switchade man in en bootloader med strömbrytarna, och sen kunde den lÀsa hÄlremsor.
Det hĂ€r var vĂ€ldigt tidskrĂ€vande, mind you. Och dyrt. DĂ„ fanns det kanske en minidator per forskningsinstitut, och alla professorer ville fĂ„ sina berĂ€kningar utförda. Professorerna lĂ€mnade sina hĂ„lremsor i en lĂ„da, och sen kom datorpersonalen och plockade upp en remsa i taget nĂ€r datorn var ledig, exekverade den, och lĂ€mnade utskriften i en annan lĂ„da. Den arbetscykeln Ă€r ganska lĂ„ng. Ăven om professorns utrĂ€kning bara tar 15 minuter att köra, sĂ„ kanske han lĂ€mnar remsan klockan 12 pĂ„ dagen nĂ€r han Ă€r klar med programmet och gĂ„r och tar lunch. Han kan komma tillbaka efter lunchen och hoppas att de har kört hans program, men nope. Sen innan han gĂ„r hem klockan 17, hittar han Ă€ntligen sin utskrift i lĂ„dan.
DÄ har han vÀntat i fem timmar pÄ att fÄ veta att det var nÄgot fel i programmet, och sÄ mÄste han göra om samma sak igen nÀsta dag.
NÀr datorer blev lite mer tillgÀngliga, och man hade uppfunnit magnetband, sÄ fanns det lite fler alternativ. Nu kunde datorerna allt som oftast lÀsa frÄn magnetband av sig sjÀlva, och arbetscykeln Àndrades drastiskt. Datorlabbet hade tre datorer: TvÄ som var specialiserade pÄ in- och utmatning, och en som var specialiserad pÄ berÀkning. Professorn kunde nu sjÀlv mata in hÄlkortet i dator A, som producerade ett magnetband med professorns program.
Datorpersonalen hĂ€mtade upp magnetbandet sĂ„ fort dator B (berĂ€kningsdatorn) var ledig, och exekverade programmet. Dator B tryckte ut resultatet till ett annat magnetband. Personalen bar magnetbandet till dator C, som skrev ut resultatet till ett papper. Fördelen med denna metod Ă€r att Ă€ven om berĂ€kningsdatorn, dator B, fortfarande Ă€r dyr, sĂ„ Ă€r dator A och C mycket billigare. Ăr det stort tryck sĂ„ kan man köpa tvĂ„ stycken av dator A, eller tvĂ„ stycken av dator C, eller av bĂ„da. Man avlastar berĂ€kningsdatorn sĂ„ att den kan jobba med det den ska, och hela processen snabbas up.
Allt som finns i datorerna Àr fortfarande en bootloader. I dator A finns ett operativsystem som konverterar information pÄ hÄlremsa till magnetband. I dator B finns programmet som professorn har skrivit, och i dator C finns ett operativsystem som konverterar informationen pÄ ett magnetband till en utskrift pÄ papper.
Men det Àr hÀr det tar vid. Den fundamentala idén kring hur datorer fungerar har inte Àndrats sÄ vÀrst mycket sen dess. En processor tar emot instruktioner frÄn ett program i RAM-minnet. Det blir inte enklare Àn sÄ. Den enklaste formen av operativsystem som nÀstan fortfarande finns i dag Àr sÄna som pÄ intel-sprÄk körs i real mode. Real mode Àr ett gammalt lÀge i intel-processorer* som Àr jÀttesimpelt. Processorn exekverar helt enkelt det som finns i RAM-minnet. Om nuvarande instruktionen i RAM-minnet Àr att tömma hela RAM-minnet, sÄ gör processorn det, laglydigt.
DOS fungerar pĂ„ det hĂ€r sĂ€ttet, till exempel. NĂ€r du startar ett program i DOS sĂ„ tar det över kontrollen över datorn helt tills du stĂ€nger det, dĂ„ det rensar ut sig sjĂ€lv frĂ„n RAM-minnet och slĂ€pper tillbaka kontrollen till DOS igen. Det innebĂ€r att programmet ocksĂ„ har full tillgĂ„ng till hela (max 1 Moâ ) RAM-minnet. Det Ă€r förstĂ„s ganska osĂ€kert. Om man har bara en pytteliten bugg i programmet sĂ„ kan man krascha hela systemet, för nĂ€r DOS fĂ„r tillbaka kontrollen kan man ha rĂ„kat Ă€ndra lite för mycket i RAM-minnet. (Finns förstĂ„s inget minnesskydd.)
Drivrutiner till DOS lÀgger sig i minnet, och registrerar sig ocksÄ direkt hos processorn, sÄ att processorn anropar dem nÀr det sker en interrupt (en (hÄrdvaru-)hÀndelse.) Sedan ger de tillbaka kontrollen till DOS, som alla andra program. Skillnaden Àr att drivrutinen hÀnger kvar i minnet, och vÀntar pÄ att bli anropad. Alla program, varenda ett, har hÀr potential att krascha ditt system. Eftersom de har full kontroll över datorn medan de körs.
Motsatsen till real mode Ă€r, vad som pĂ„ intel-sprĂ„k kallas, protected mode (skyddat lĂ€ge). Det ger minnesskydd, möjlighet till mer Ă€n 16 bitar (32 och 64 Ă€r vanligt) vilket i sin tur ger tillgĂ„ng till mer Ă€n 1 Mo RAM-minne och lite annat gott. Allt jag pratar om i fortsĂ€ttningen Ă€r i pmode.âĄ
En monolitisk kĂ€rna (monolithic kernel) pĂ„minner om den i DOS, fast Ă€r Ă€ndĂ„ lĂ„ngt dĂ€rifrĂ„n. Eftersom man har minnesskydd och icke-linjĂ€r exekvering finns Ă€ven stöd för multitasking pĂ„ ett sĂ€kert sĂ€tt. Det innebĂ€r att flera program kan köras »samtidigt.« Det som egentligen hĂ€nder Ă€r att processorn kör ett program i taget, men vĂ€xlar sĂ„ snabbt mellan program att det verkar som att de körs samtidigt. Ă
h, flera program! F1 nice! DÄ borde man vÀl typ kunna göra operativsystemet till en kÀrna, och sÄ körs alla program utanför den, och bÄda lever samtidigt? Yup. SÄ gör man ocksÄ. Windows (versioner större Àn 95, dock inte NT) gör sÄ. BSD gör sÄ. Linux gör sÄ. OS X gör sÄ.
Skillnaden Àr nu alltsÄ att programmen körs övervakade i user space. Att de Àr övervakade betyder att om de försöker komma Ät och/eller Àndra en minnesaddress de inte har rÀtt till, sÄ sÀger systemet till. I *nix-system sÄ skickar kÀrnan en signal som heter SIGSEGV, och eftersom programmet inte svarar pÄ den dödas det (Àlskar att *nix dödar program som inte svarar,) och oftast fÄr man utskriften »Segmentation fault.« PÄ Windows fÄr man en pop-up (ofc) med text i stil med, »has encountered a problem and needs to close.«
This is all nice. Men drivrutiner dÄ? Det Àr en annan historia. De kan fortfarande vara kompilerade in i kÀrnan. DÄ laddas de in samtidigt som kÀrnan. En annan modell för monolitiska system Àr att drivrutiner kan i efterhand laddas in som moduler in i kÀrnan. Denna modell har *nix anvÀnt sig av ganska friskt, och Windows gör det ocksÄ, till viss del. Den stora skillnaden Àr att Windows bara kan ladda in drivrutiner nÀr man startar datorn. Detta Àr en av anledningarna att man mÄste starta om Windows sÄ ofta. Med *nix kan man ladda in drivrutiner under drift (kommandot modprobe kanske kÀnns igen.)
Fördelar? Att ha drivrutiner som en del av kÀrnan gav en ganska rejÀl prestandaskjuts för 20-30 Är sedan. Eftersom kÀrnan kan anropa drivrutiner lite hipp som happ utan att behöva tÀnka pÄ nÄgot gÄr det rÀtt snabbt.
Nackdelar? Drivrutiner Àr fortfarande en del av kÀrnan, och en bugg i en drivrutin kan krascha hela ditt system. (Varit med om blue screens i Windows? That's right, det Àr troligtvis en drivrutin som har segfaultat.)
Windows NT och högre (XP, Vista, 7) tar en intressant stÄndpunkt hÀr. De har mÄnga punkter som Àr karaktÀristiska för en monolitisk kÀrna, som att drivrutiner, nÀtverk och sÄ vidare körs i kÀrnan. DÀremot finns det vissa saker hos operativsystemet som inte gör det. Till exempel filsystemet. DÀremot Àr det en hel del som vanligtvis körs i user space (grafiska delen) som Microsoft har lagt in i kÀrnan i Windows pÄ grund av prestandaskÀl.
Att Windows NT inte riktigt Àr en monolitisk kÀrna, men nÀstan, har fÄtt den att anta etiketten hybridkÀrna eller makrokÀrna. Det innebÀr helt enkelt att de har ungefÀr lika mycket saker i kÀrnan som monolitiska operativsystem, men somliga saker som traditionellt ligger i kÀrnan har de lagt i user space.
Ett alternativ till den monolitiska kÀrnan Àr mikrokÀrnan (micro kernel.) Nackdelen med den Àr att man kan fÄ en prestandaminskning pÄ kanske 10% (frisk gissning, för 20 Är sedan var det 20%. Nu Àr det antagligen en hel del mindre.)
Hur kommer det sig? Vad gör mikrokÀrnan som Àr lÄngsammare?
Minns du att i en monolitisk kÀrna körs programmen i user space? I en mikrokÀrna körs allt i user space. Allt som kan köras i user space i alla fall. Det inkluderar drivrutiner, filsystem, nÀtverkssystem och sÄ vidare. Minns du fördelen med att programmen kördes i user space? Just det, de var övervakade. Med en mikrokÀrna kan Àven drivrutiner övervakas, eftersom de ocksÄ körs i user space.
Detta Ă€r ganska tydligt stabilt. I ett experiment provade man att föra över en stor fil mellan tvĂ„ datorer. PĂ„ ena datorn körde man ett operativsystem med en mikrokĂ€rna (Minix). PĂ„ det systemet simulerade man krascher av nĂ€tverks- och filsystemet genom att döda respektive drivrutin massor av gĂ„nger. Ăvervakningen kunde lugnt starta om dem och fortsĂ€tta filöverföringen. Filen var inte korrupt nĂ€r den kom fram, trots att grundlĂ€ggande, vitala delar av systemet blev avstĂ€ngda flertalet gĂ„nger under överföringen.
Det Ă€r kraften hos en mikrokĂ€rna. Ăven om nĂ„got sĂ„ vitalt som filsystemet i din dator dör, sĂ„ kommer:
Det inte direkt pÄverka nÄgot annat program (jÀmför med blue screen eller kernel panic som tvingar dig att stÀnga av hela datorn)
Det kunna startas om sÄ fort systemet mÀrker att det har dött
BetÀnk Àven en lite sÀllsyntare hÀndelse som att en drivrutin fastnar i en oÀndlig loop. Det skulle med en monolitisk kÀrna innebÀra att hela systemet hÀnger sig. Med en mikrokÀrna sÄ kan systemet ge drivrutinen lÀgre och lÀgre prioritet (tona ut hur stor effekt oÀndliga loopen har pÄ resten av systemet) och till sist starta om drivrutinen om den inte kommer loss.
Nackdelen var som jag redan nÀmnt, att det hÀr krÀver lite mer prestanda. Eftersom drivrutiner och sÄnt körs som i program i user space sÄ kan kÀrnan bara kontakta dem genom att skicka runt meddelanden till deras processer. Detta krÀver lite mer kraft Àn vad som krÀvs för att bara anropa en modul i kÀrnan. Det Àr Àven jobbigare att implementera en mikrokÀrna (i alla fall enligt folk som kan sÄnt dÀr) frÄn början. Fun fact: Torvalds skrev Linux inspirerad av Tanenbaums bok om Minix. Minix Àr baserat pÄ en microkernel, och Linux Àr en monolitisk kÀrna. Hur gick det till? Torvalds har mig veterligen inte svarat pÄ det. Kanske var han lat, kanske missförstod han Tanenbaum pÄ en av de viktigaste punkterna. :)
Varför kör vi fortfarande med monolitiska kÀrnor överallt? FrÄga inte mig.
* NÀr jag skriver »intel-processorer« menar jag »processorer som Àr kompatibla med intels 8086-processor.« Det innefattar alla intels och AMD:s nuvarande modeller, sÄ vitt jag vet.
För övrigt Àr intel-processorer retarderade. Varför de har bestÀmt sig för att alla splitter nya processorer som sÀljs ska vara kompatibla med DOS 1.0 Àr bortom min förstÄelse. Att de dessutom kör en CISC-tolk pÄ en RISC-kÀrna för att RISC visade sig vara snabbare Àr bara helt otroligt. Envisa jÀvlar. Intel och alla som följer i deras spÄr Àr urmammorna till alla hÄrdvarufulhakk. (Sa nÄgon gate A20?)
â Mo stĂ„r för megaoctet. NĂ€r jag pratar om 8 bitar föredrar jag termen octet, eftersom en byte kan vara olika stor. Dessutom Ă€r byte förvirrande, eftersom det förkortas med samma bokstav som bit. Jag rekommenderar er att börja anvĂ€nda octet nĂ€r ni pratar om 8 bitar ocksĂ„. En byte stĂ„r bara för minsta addresserbara enheten, och Ă€r i de flesta PC:s lika med en octet. Dock Ă€r sĂ„ inte alltid fallet.
⥠Protected mode. Eller som vanligt folk (som inte har med intel att göra) skulle sĂ€ga: NORMALT JĂVLA LĂGE. Det Ă€r ganska bra om du förstĂ„r att real mode inte har rĂ€tt att existera i dag. Det finns ingen vettig anvĂ€ndning för det och det Ă€r helt sjukt att de har behĂ„llt det.
