Preliminär specifikation

Projektnamn: Educational Operating System (EOS)

Uppdragsgivare: Virtutech

Projektgrupp:

Bilagor: Begrepp och akronymer

1.

Problembeskrivning

1.1 Bakgrund
  Linux och andra operativsystem, som är vitt spridda och gratis att använda, är inte designade för att vara enkla att förstå och de illustrerar inte heller de inre delarna hos ett operativsystem på ett bra sätt. Bakgrunden till det här projektet är att skapa ett operativsystem med kod som är enkel att följa och utöka för att kunna utnyttjas i studiesyften.
1.2 Syfte
  Att implementera ett litet och lättförståeligt operativsystem som ska kunna användas tillsammans med Simics i utbildningssyfte.
1.3 Krav och avgränsningar
1.3.1 Funktioner
  operativsystemet ska kunna bootas från en diskett. Användare ska ha tillgång till ett enkelt textbaserat interface och kunna köra flera program/trådar samtidigt, dock inte kunna skapa egna program.

Då det handlar om ett (utbildnings-)operativsystem, är det viktigt att också nämna de "inre" funktionerna i systemet, dvs. vad systemet ska klara av att göra.
  • Enkel I/O - utskrift till skärm och läsning av tangenttryckningar på tangentbordet
  • Multitaskning - flera processer ska kunna köras samtidigt
  • Virtuellt minne - varje process får "sin egen" adressrymd som är skyddad från övriga processers adressrymder. Detta innebär att man som programmerare inte behöver tänka på var i minnet programmet kommer att hamna, samt att en process inte kan förstöra för andra processer.
  • IPC - Inter Process Communication; en process ska kunna synkroniseras samt samarbeta med andra processer.
1.3.2 Datormiljö
1.3.2.1 Hårdvara
  x86 processor (Intel Pentium eller AMD).
Tangentbord, monitor samt diskettenhet.
1.3.2.2 Mjukvara
  Simics för den som inte vågar boota operativsystemet på riktigt.
1.3.3 Användare
  OS-utvecklare, datorteknikstuderande samt Simicsanvändare. Användaren bör ha goda kunskaper i C/C++.
   

2.

Förslag till lösning

2.1 Systemskiss
2.1.1 Moduler
 
  • Nanokärna (nano-Kernel)
    Nanokärnan ska kunna hantera kontextbyten. Dessa sker då schedulern byter process och innebär att innehållet i CPU:ns register måste sparas undan och den nya processerns data laddas in. Kärnan ska också kunna hanter interrupts, t.ex. klockan. Då ett interrupt kommer så ska något utföras och det är kärnans uppgift att se till att rätt kod exekverar. Dessutom ska kärnan tillhandahålla de andra systemmodulerna med hårdvarunära kod (assembler kod). Ett annat sätt att se på saken är att nano-kärnan är den enda modulen som är processorarkitektursberoende, och dess uppgift är att abstrahera hårdvaran så pass mycket att de övriga modulerna utan (eller med liten) modifiering kan köras på vilken processortyp som helst.
  • Minneshantering (MM)
    Den "fysiska" minneshanteraren ska dela upp hela minnet i frames (ramar) av samma storlek. Den ska sedan hålla reda på vilka av dessa frames som används och vilka som är lediga. Den ska ge virtuella minneshanteraren möjlighet att allokera och deallokera frames.
  • Virtuell minneshantering (VMM)
    Virtuella minneshanteraren ska skapa pagetabeller för det antal processer som operativsystemet maximalt tillåter. Den ska också starta MMU:n som är en hårdvaruenhet vilken utnyttjar pagetabellerna för att översätta minnesanrop som olika processer gör. Virtuella minneshanteraren har också som uppgift att skapa inlägg i pagetabellerna så att MMU:n vet vilket minne som är tillgängligt för en process och vart det ligger.
  • Input/output (I/O)
    Input/Output-modulen ska ge operativsystemet möjlighet att skriva ut tecken på en monitor och läsa tecken från ett tangentbord.
  • Minimalt standard C/C++ bibliotek (libc + libcpp)
    C/C++ bibliotekets uppgift är att erbjuda standardiserade C/C++ funktioner för att få tillgång till modulernas olika funktioner. Dessa kommer användas av både operativsystemet och användarprogram. Att ha detta bibliotek underlättar, eftersom det då går att skriva "normal" C/C++-kod, som ju vanligtvis innehåller många anrop till C/C++-standardfunktioner. New, delete, malloc och free är några funktioner som ska finnas när det gäller minneshantering. Containerobjekt som arrayer och listor ska det också finnas stöd för. Dessutom ska printf och getc finnas för att kunna kommunicera med I/O-modulen.
  • Schemaläggare (Scheduler)
    Schemaläggaren ska ge systemet möjlighet att skapa processer och erbjuda dessa rättvis tillgång till processorkraft. Den ska också blockera processor som väntar på input så att de inte tar processortid i onödan. Schemaläggaren måste dessutom göra det möjligt att ta bort processer.
2.1.2 Diagram
 
2.2 Skiss av användargränssnittet
  Ett textbaserat interface till utseende som en terminal på xwindows eller ett MSDOS-fönster. Den kommer dock inte erbjuda mer kommandon än att starta eller avsluta processor och skriva ut information om systemet, givetvis också ett "help"-kommando.
   

3.

Genomförande

3.1 Metod
 

eXtreme Programming i den mening att vi inte spenderar så mycket tid att specificiera och dokumentera projektet. Dessutom sker all programmering i grupper på två personer och all kod är öppen så att alla kan göra ändringar i den.

3.2 Ansvarsfördelning i gruppen
 

Projektledare: Jens Lindh
Sekreterare: Peter Wåhlander
Byggmiljö: Åke Wallebom
CVS-ansvarige: Gilbert Netzer
WWW-ansvarig: Daniel Eklöf

nano-Kernel: Daniel Eklöf och Gilbert Netzer
MM+VMM: Kalle Berglund och Jens Lindh
Scheduler: Daniel Felke och Peter Wåhlander
I/O: Åke Wallebom
libc + libcpp: hela gruppen

3.3 Tidsplanering av aktiviteter
 
  • Vecka 7:
    • Första mötet med Virtutech
  • Vecka 9:
    • Samtliga projektdeltagare ska ha tillgång till Simics
  • Vecka 10:
    • Andra mötet med Virtutech
    • Preliminära specifikationen ska vara färdigskriven
    • Tentavecka
  • Vecka 11:
    • Tentavecka
  • Vecka 13:
    • Preliminära specifikationen ska vara omarbetad enligt kursledarens krav
    • Lägesrapportmöte med kursledaren
    • I/O ska vara färdigskriven
  • Vecka 14:
    • Schedulern ska vara färdigskriven
    • Minneshanteraren ska vara färdigskriven
  • Vecka 15:
    • Interrupthantering ska vara färdigskriven
    • Bygg ihop ett preliminärt system
    • Tredje mötet med Virtutech
  • Vecka 16-18:
    • Påsklov
    • Refactoring dvs. omskrivning och förenkling av koden
    • Testning av systemet och reperation av eventuella buggar
    • Dokumentering: användarhandledning och projektrapport
    • Förhandsvisning för kursledaren
  • Vecka 19-21:
    • Slutredovisning och inlämning av projektet
  • Övrigt:
    • Minst ett möte varje vecka
    • Färdigskrivandet av libc/libcpp sker i takt med att de andra modulerna blir färdigställda
3.4 Administration
  Varje vecka träffas hela gruppen på ett möte där vi stämmer av hur arbetet fortskrider. Här finns också chans att ställa frågor och få hjälp av de övriga i gruppen. Dessutom vidarutvecklas operativsystemets design. Annan kommunikation sker i första hand på vårt forum som tillhandahålls av Virtutech. Forumet läses även av våra handledare vilka kan bidra med sin expertis. Själva resultatet av allt arbete, dvs. kodfilerna, sparas under ett gemensamt CVS-träd (http://www.cvshome.org/). På så sätt finns det möjlighet för flera personer att jobba på samma sak samtidigt och göra ändringar i annan kod än ens egen. I nödfall sker även kommunikation genom e-mail.
3.5 Aktivitet: Implementation
  Se 3.3
3.6 Arbete med dokumentation
  Målet är att skriva bra kod som ska kunna läsas av intresserade dessutom ska det gå att generera dokument direkt ifrån koden. För att göra det används Doxygen (http://www.stack.nl/~dimitri/doxygen/). Användarhjälp för de som är inne i själva operativsystemet sker genom den textbaserade konsolen. För detta tillhandhålls ett kommando "help". Vi kommer även att ge en beskrivning av hur man laddar in och kör operativsystemet under Simics. Det är ett dokument som kommer att skapas under projektarbetets gång, allt eftersom vi själva lär oss att använda Simics.
   

4.

Riskanalys

 
Risk Skada Sannolikhet Åtgärd
Kunskapsbrist Hög Hög Sök information och fråga om hjälp.
Kommunikationsbrist Hög Medel Forumet, mail och CVS
Fulkod Hög Medel Refactoring
Tidsbrist Låg Hög Downsizing
Synkronisering Låg Hög CVS och forumet
Datorhaveri Låg Låg Backups
   

 


$Id: preliminar_spec.html,v 1.16 2003/03/24 13:27:20 d00-jli Exp $