Design och trender. Föreläsning 12

Transkript

1 Design och trender Föreläsning 12

2 Design och trender Varför är det svårt att skriva OS? Vad ska man tänka på när man implementerar OS? Vart är utvecklingen på väg? Fortsättningskurser för den som vill lära mer Design av OS Trender trender 2

3 Design Designmål Svårigheter Implementation Prestanda Projekthantering

4 Designmål Man kan inte lösa alla problem med ett enda system! PL/1, MULTICS, tidiga versioner av Windows Har man klara och tydliga mål går det lättare: Vilka abstraktioner vill man använda? Vilka primitiva operationer tillhandahåller man? Hur skyddar man olika delar/användare från varandra? Hur hanterar man hårdvaran på ett effektivt sätt? trender 4

5 Varför är det svårt att skriva OS? 1. Storlek och komplexitet Vista c:a 70 miljoner rader kod Windows 2000 är 29 miljoner rader kod Solaris 2 miljoner rader kod Linux 2.5 miljoner rader kod FreeBSD 1.5 miljoner rader kod 2. Olika delar samverkar med varandra Virtuellminnet och filsystemet via t.ex. buffercachen trender 5

6 Varför är det svårt att skriva OS? 3. OS måste hantera parallellitet Processer Hårdvaruenheter (I/O) Flera CPUer 4. Säkerhet Skydda sig mot inkräktare, insiders som vill göra skada, misstag från användare Att dela resurser Användare vill inte vara fullständigt isolerade från varandra man måste tillåta kommunikation, delande av resurser trender 6

7 Varför är det svårt att skriva OS? 6. Det är svårt att förutsäga framtiden: Operativsystem är förvånansvärt långlivade Unix börjar närma sig 40 år MS-DOS är ungefär 30 år 7. Portabilitet Ska helst köra på många olika typer av datorer Ska tillåta många nya typer av hårdavruenheter att läggas till Ska underlätta att flytta tillämpningar 8. Kompatibilitet med gamla misstag Nya versioner bör kunna köra gamla program och användas av gamla användare trender 7

8 Vikten av bra gränssnitt - tänk på användarna!!! Operativsystemet ska underlätta för användarna! Den vanlige användaren Hur används OS:et Systemadministratören Hur administreras OS:et Programmeraren Systemanrop, biblioteksfunktioner Hårdvarutillverkaren Gränssnitt mot device drivers trender 8

9 Grundläggande designprinciper Enkelhet Perfection is reached not when there is no longer anything to add, but when there is no longer anything to take away Ex: ett fåtal väl designade systemanrop som bara gör enkla saker Fullständighet Everything should be as simple as possible, but no simpler Allt man behöver kunna göra måste gå att göra Effektivitet Om något inte kan göras på ett effektivt sätt kanske det inte skall vara ett systemanrop trender 9

10 Paradigmer/abstraktioner - vilken modell exporterars/pådyvlas användaren Användargränssnittet Kommandoradsstyrt Grafiska användargränssnitt En look-and-feel hos alla applikationer Ett enda GUI eller kan användaren välja? Var implementeras GUI? Exekvering Algoritmisk man vet från början vilken funktion programmet/processen skall utföra Händelsestyrd asynkrona händelser styr vad som skall ske trender 10

11 Dataabstraktion Ett OS bör ha en generell abstraktion i botten Unix: allting är en fil Windows NT: allting är ett objekt Ger en enhetlig modell för systemanrop Ex: Samma typ av mekanism för att läsa från terminalen som från en fil eller en pipe trender 11

12 Systemanrop Tror man på det vi sagt tidigare så ska OS:et: Tillhandahålla så få systemanrop som möjligt Systemanropen skall bara göra en sak Adding more code adds more bugs Don t hide power trender 12

13 Implementation Struktur Mekanism och policy Ortogonalitet Namngivning Bindningstid Implementationstekniker Prestanda

14 Systemstruktur - monoliten Ingen egentlig struktur allt är hopkopplat till en enhet Orginal UNIX, LINUX, MS-DOS Inte nödvändigtvis en eftersträvansvärd struktur... trender 14

15 Systemstruktur - skiktade system Skiktade system (layered systems) är ganska vanliga Solaris Windows NT Varje lager löser vissa problem som högre lager kan strunta i Varje lager implementerar en virtuell maskin trender 15

16 Systemstruktur - exokärnor och utvidgningsbara OS Exokärnor: Ge endast minimal funktionalitet Om en användarprocess kan implementera X så har X inte i OS att göra Det mesta görs i användarbibliotek I princip endast skydd och resurshantering i OS Exempel: OS ger ej paritetsskydd av filer Checksumman lagras separat Användarprocessen gör kontrollen själv Utvidgningsbara OS (extensible) Minimal grundfunktionalitet Extra funktionalitet kan adderas enkelt och modulärt trender 16

17 Systemstruktur - klient-server Klient-serversystem lägger funktionalitet i servers utanför kärnan Filservrar klassiskt exempel Även drivrutiner kan struktureras som egna processer om de kan få access bara till rätt hårdvara Vanligt i forskningsvärlden Mach (har använts som grund för kommersiella OS) Amoeba (har bara ett systemanrop!) trender 17

18 Separera mekanism och policy Ex: Schemaläggning Mekanism: Kör den tråd som ligger först i den icke tomma ready lista som har högst prioritet Policy: Bestäm vilken prioritet olika trådar har Ex: Minneshantering Mekanism: Hur man skriver ut eller läser in sidor, hur man ändrar i sidtabellen Policy: sidutbytesalgoritmen trender 18

19 Ortogonalitet Funktionalitet skall gå att kombinera Ex: C har grundläggande datatyper som man kan bygga sammansatta med, vektorer, matriser, structs Ex: LINUX kan skapa allt på en glidande skala från processer till trådar med clone() trender 19

20 Namngivning Hur ser namn ut som användaren ser? Hur hanterar man namn internt Översättning mellan intern representation och extern Flera namnrymnder Windows objekt, filer, registryn, Active Directory + interna namnrymnder... trender 20

21 Bindningstid När binder man saker och ting? När bestäms var en process laddas i minnet adressöversättning När länkas bibliotek in När allokeras minne för variabler När kan device drivers laddas trender 21

22 Implementationstekniker Dölj hårdvaran Inkapsling med gemensamt gränssnitt Indirektion Ex: VFS, egendefinerade datatyper Återanvändbar kod Debugga koden en gång! Reentrant kod Brute force Var smart bara om det verkligen lönar sig annars tar man den enkla lösningen Kontrollera eventuella felfall först innan man gör en massa i onödan trender 22

23 Optimeringar Hopklumpning Cachning Copy-on-write Lokalitet Vad ska optimeras?

24 Hopklumpning Klumpa ihop flera små operationer till en större, ofta med hjälp av buffring I/O använder buffring i flera steg Biblioteksrutinerna fread() och fwrite() samlar ihop flera operationer innan de gör systemanrop Systemanropen read() och write() kan samla ihop flera operationer innan de gör diskaccess Minnesallokering Biblioteksrutinen malloc() allokerar oftast en stor klump åt gången med sbrk() trender 24

25 Cachning och lokalitet Utnyttja lokalitet för cachning Samma data kommer att behövas flera gånger i nära tid Närliggande data kommer att användas (readahead) Ex: Buffer-, page-cache Lokalitet Working set Working directory trender 25

26 Copy-on-write Om flera processer skall ha egna kopior av ett stort objekt kan man spara mycket på att bara kopiera objektet då det skrivs Ex: I Unix följs fork() ofta snart av exec() Då kan det vara smart att inte kopiera hela adressrymden direkt efter fork() trender 26

27 Exempel: Copy-on-write av adressrymder vid fork() Sparar den mesta kopieringen vid fork() som snart följt av exec() Endast sidtabellerna kopieras till en början Både barnets och förälderns adressrymd skrivskyddas Alla platser i sidtabellerna markeras read-only Vid läsning ser det ut som om en kopiering gjorts trender 27

28 Exempel: Copy-on-write av adressrymder vid fork() Om barnet eller föräldern skriver kopieras den sidan Skrivningen upptäcks genom att det blir skyddsfel En ny sida allokeras och länkas in i skrivarens addressrymd Sidan är inte längre delad, så den markeras som skrivbar igen i både barnet och föräldern trender 28

29 Optimera eller inte? Prestanda optimeringar bör man göra bara där man vet att det behövs! Det vanliga fallet där man veta att man behöver spara tid Ta inte till krångliga/komplexa algoritmer och datastrukturer om de inte verkligen behövs! trender 29

30 Att driva stora komplexa projekt Var spenderas tiden Ex: 30% planering, 15% kodning, 25% modultest, 25% integration/systemtest, 5% annat Att addera mer resurser (personer) i ett sent skede av ett projekt försenar oftast projektet Dåliga nyheter kommer alltid för sent... Erfarenhet viktigt!!! trender 30

31 Trender Inte lätt att sia om framtiden

32 Lite historia 1986 Intel 286i 8 Mhz processor 640 KB primärminne Den var aldrig speciellt långsam!!!! Nu 3 Ghz processor, 4 kärnor, 8GB primärminne, disk ~3 TB Långsam, för lite disk, för lite minne... Varför? Mer och mer features... Hur får man annars någon att betala för nästa release... Vart är vi på väg? trender 32

33 Stora adressrymder Stora adressrymder (64-bit) och nya minnestekniker ger nya möjligheter Filsystemet i den virtuella addressrymden Filer ersätts av objekt (eller andra data strukturer) Persistent minne trender 33

34 Nätverk Distribuerade operativsystem (forskning) med transparent namngivning av objekt cachning av objekt migration av processer Peer-to-peer system Man kanske inte behöver distribuerade OS Stöd för att bygga distribuerade system ovanpå OS:et Overlay networks Big Data Hadoop med YARN trender 34

35 Mobila nät Mobila system har olika grad av kontakt Ingen (disconnected operation) Liten (trådlös kommunikation) Stor (trådförbindelse med nätet) Självorganiserande strukturer/nät Filsystem som kan vara isolerade och sedan anslutas till nätet igen (uppdateringar) Energihantering i samarbete mellan OS och tillämpning Contiki OS från SICS trender 35

36 Säkerhet Säkerhet på alla nivåer Applikation Dator Nät trender 36

37 Multimedia Multimedia program kräver realtidsegenskaper av hela kedjan Server Nät PC (eller motsvarande) trender 37

38 Om Kanske datorn som sådan försvinner? Set-top-box X-box (eller andra spelkonsoler) Ipad En pryl som bara gör en sak är lättare att använda Om hårdvaran blir liten, lätt och billig kan man köpa ny maskin när man vill ha nytt program trender 38

39 Sammanfattning trender 39

40 Fö 1: Vad är ett OS? Applikationer ex. Webb, spel, administrativa system Editorer Kommandotolk/shell Kompilatorer Operativsystem Systemanrop Säkerhet CPU/Processer Minneshantering Filsystem Kommunikation I/O User space Kernel space Maskininstruktioner Mikroarkitektur Fysiska komponenter trender 40

41 Fö 1: Processer Vad är en process? Varför processer? trender 41

42 Fö 2: Minneshantering Fysisk vs. Virtuell adressrymd Adressöversättning Allokering Sidindelning Sidtabeller Vanlig Flernivåer Inverterad TLB Swapping trender 42

43 Fö 3: Virtuellminne Demand paging Sidutbytesalgoritmer Working set trashing Segmentering trender 43

44 Fö 4: Filsystem Filer Directoryn Implementation av filsystem Organisation av hårddisk Exempelfilsystem trender 44

45 Fö 5: I/O Användarprog biblioteksfunktion systemanrop kod i kärnan Abstraktioner för I/O I/O styrning Pollning Avbrott DMA Buffring/cachening Hårddiskar, grafik mm. trender 45

46 Fö 6: Trådar och multiprocessorer Trådar vs processer Trådar Användarläge Kärnan Multiprocessorer Varför? Sammanbindningsnät Schemaläggning Introduktion till synkronisering trender 46

47 Fö 7: Synkronisering Kritisk sektion race-condition Synkroniseringsprimitiver Deadlock Livelock Coffmans villkor Undvika/återhämta sig från deadlock Svältning trender 47

48 Fö 8: Realtidsystem, device drivers Realtidssystem Karaktäristika Schemaläggning Stöd från OS Device drivers Vad är det? Hur implementeras det? Hot-plug-and-play/dynamiskt laddade device drivers trender 48

49 Fö 9: Distribuerade system Terminologi Nätverk Kommunikation Designmål! RPC Distribuerade OS Distribuerade objektsystem Distribuerade filsystem AFS/NFS trender 49

50 Fö 10: Säkerhet Vad skyddar man Var skyddar man Attacker Virus Maskar Trojaner Lösenord Återhämtning trender 50

51 Fö 11: Fallstudier LINUX/UNIX WINDOWS/VISTA trender 51

52 Vad läser man sedan? Säkerhet Kryptering NADA Internet security ICT/ECS Kommunikation Internetworking mm. ICT/ECS Kommunikation NADA-KTH-NOC Big DAta Hadoop mm. ICT/SICS Datorsystem ICT/ECS Trådlösa system - Wireless centret Distribuerade/parallella system All programvara interagerar någonstans mot OS trender 52

53 Prestandautvärdering Mät rätt saker Mätnogrannhet Reproducerbarhet trender 53

54 Tack för mig! Lycka till på tentan! Fortsätt lära er kunskap kan ingen ta i från er trender 54