Kom godt i gang

Først og fremmest er udvikling af et operativsystem nok noget af det mest udfordrende, du kan gøre på en computer (næst efter at dræbe den sidste boss i Doom på sværhedsgrad Nightmare). At sammensætte et styresystem kræver en masse viden om flere komplekse områder inden for datalogi. Du skal forstå, hvordan hardware fungerer, og du skal kunne læse og skrive det komplekse assemblagesprog samt et sprog på højere niveau (f.eks. C, C++ eller Pascal). Din hjerne skal være i stand til at pakke sig ind i abstrakt teori og rumme et utal af tanker. Føler du dig endnu ikke modløs? Du skal ikke være bange! For alle disse ting er også de ting, der gør OS-programmering sjovt og underholdende.

Der er intet som følelsen af at have opnået noget, når du endelig, efter at have kæmpet i timevis, løser problemet. Og efter noget tid kan du se tilbage og se alle de ting, du har skabt fra bunden. Dit håndskrevne system er i stand til at starte op, udfører magi mod hardwaren og giver brugeren en brugergrænseflade og programmer at lege med.

Der er ingen absolut vej, man skal gå, når man skaber et operativsystem. Når du har fået dit første system op at køre (og det gør du ved at finde passende tutorials), vælger du selv den vej, du vil gå videre ad. Dit OS er præcis det – dit. Du har den ultimative kontrol, og der er ingen grænser for, hvad du vil!

• 1 Den hårde sandhed
• 2 Ansvar
• 3 Nødvendig viden
• 4 Organiser dine planer
• 5 Valg af udviklingsmiljø
  • 5.1 GNU/Linux
  • 5.2 Windows
  • 5.3 MacOS
• 6 Test af dit styresystem
• 7 Beskyttelse af din kode
• 8 Fælles udgangspunkt
• 9 Opnå yderligere viden
• 10 Se også
  • 10.1 Artikler
  • 10.2 Tråde
  • 10.3 Eksterne links

Den hårde sandhed

Håber ikke, at den grundlæggende kendsgerning, at udvikling af operativsystemer er en kompliceret og vedvarende proces, afskrækker dig. Sandheden er, at udvikling af operativsystemer virkelig er uden sidestykke, da det kræver den største tålmodighed og omhyggeligt kodedesign, og det giver meget lidt eller ingen “øjeblikkelig tilfredsstillelse”, som du får ved udvikling af ting som spil og web-baseret scripting.

Du er blevet advaret om det hårde arbejde, der venter forude, men hvis du stadig er interesseret, så gå videre ind i operativsystemprogrammørens verden. Forbered dig på lejlighedsvise anfald af forvirring, modløshed og for nogle af os … midlertidig sindssyge. Med tiden, og med tilstrækkelig hengivenhed, vil du finde dig selv blandt de få elitefolk, der har bidraget til et fungerende styresystem. Hvis du bliver modløs undervejs, kan du genopfriske dig selv med indholdet i denne bog. Forhåbentlig vil det minde dig om, hvorfor du i første omgang begyndte på en så vanvittig rejse.

På dette tidspunkt kan det også betale sig at læse siden Begynderfejl. Brugere på forummet har bemærket, at mange af disse fejl bliver gentaget med tiden, og at undgå dem er en god måde at undgå at gøre dig selv til grin på.

Ansvar

Mennesker har en tendens til at hævde, at det er OK at skrive ineffektiv software, idet de hævder, at computersystemer er så hurtige i dag, at du ikke vil kunne se virkningen. Denne type mentalitet er farlig i forbindelse med design af styresystemer. Det er måske OK at skrive sjusket kode, når man laver et simpelt program, men når det drejer sig om kritisk kode, der kan blive kaldt tusindvis af gange i sekundet, skal man fjerne alt det overhead, man kan. Operativsystemet skal levere computeren som en grundlæggende ressource til de kørende programmer med så lidt komplikation, abstraktion og overhead som muligt.

De mennesker, der designer operativsystemer i vore dage, har en tendens til at have “alt undtagen køkkenvasken”-mentaliteten. De påtager sig at tage højde for alting, hvilket naturligvis er godt, men det bør ikke ske på bekostning af at lade dårligt skrevne programmer blomstre. Der er mange ting, der foregår “under motorhjelmen”, når der opstår programfejl. Dårligt skrevne programmer koster kostbar eksekveringstid og indebærer opgaveskift, der er dyre i både hukommelse og frekvens. Vi opfordrer dig til at fraråde dårligt skrevet software.

Nødvendig viden

Hovedartikel: Krævet viden

Hvis du mener, at du kan springe dette over, er det lige noget for dig.

Dette afsnit er blevet flyttet til en separat side, fordi der henvises så ofte til det i forumdiskussioner.

Organiser dine planer

Hvor du går videre, skal du overveje, hvad det er, du ønsker at få ud af at skrive et operativsystem. Hvad er dine motivationer for at påtage dig dette projekt? Der er mange mulige grunde til at påtage sig et hobby OS-projekt, og de fleste os-devers har mere end én. Bare at sige “jeg har bare lyst til” kan være nok, men jo mere du overvejer og præciserer dine mål og motiver, jo mere kan du fokusere på det, du virkelig ønsker.

Vær også ærlig over for dig selv. Der er ingen skam i at have større ambitioner for dit projekt, selv (eller især) hvis de ikke er det primære mål. Prøv at anerkende alle dine mål, ikke kun det, du mener er dit hovedformål.

Forsøg at slå dig fast på, hvilke aspekter af OS-designet du er mest interesseret i eller ser et behov for at arbejde med. Det meste af det, der indgår i OS-udvikling, især tidligt, er design og udvikling af kernen, men selve kernen er kun en lille del af de fleste operativsystemer; hvis din primære interesse er UX, eller netværk eller driverprogrammering, bør du overveje, om du virkelig har behov for (nu eller i fremtiden) at skrive dit eget OS overhovedet, eller om du ville være lige så tilfreds med at udvikle disse ting på en eksisterende kerne. Mere end et par mennesker er gået ind i OS-udvikling, når de egentlig ønskede at designe et desktop-miljø, så det er et meget vigtigt spørgsmål at stille sig selv.

Forsøg at tænke på eventuelle ikke-OS-projekter, som du måske ønsker at tage fat på først eller samtidig, især projekter, der kan tjene som øvelse eller forberedelse til OS-projektet. Der er normalt ingen grund til at arbejde på OS-projektet lige nu, og jo mere du har forberedt dig på forhånd, jo bedre er du stillet (i hvert fald indtil et vist punkt – forberedelse er én ting, udsættelse er noget andet).

Sådan er det også, hvis du har til hensigt at arbejde på at forke et eksisterende design for at eksperimentere med det eller for at ændre det til et bestemt formål, så fokuser på det frem for generelle udviklingsspørgsmål. Overvej hvilke dele af den eksisterende kodebase du vil have brug for, og hvilke du vil ændre.

Forsøg at udarbejde nogle af dine specifikke projektmål, og vær parat til at planlægge separate projekter, hvis det hjælper. Hvis du blot har til hensigt at rode rundt og se, hvor det fører dig hen, er det fint; hvis du har til hensigt at vælte Microsoft, er det også fint (om end nok urealistisk). Når du ved, hvad du vil gøre, kan du nedbryde detaljerne i det i specifikke mål og finde ud af, hvad der skal til for at nå dem. Forsøg ikke at tvinge for mange divergerende mål ind i ét projekt – hvis du har forskellige ting du vil prøve med modstridende mål, så del dem op i forskellige projekter.

Det kan hjælpe hvis du skriver en oversigt over dit planlagte OS-design, med alle specifikke krav eller detaljer du mener er bemærkelsesværdige eller som kan tydeliggøre hvad du har brug for hjælp til, og tilføj det til dit offentlige repository, hvis du kan. Dette vil ikke kun gøre det nemmere for andre at hjælpe dig, det vil hjælpe med at organisere og stabilisere dine planer, lidt ligesom at skrive en skitse til en historie eller en opgave. Vær forberedt på at vedligeholde det, efterhånden som dine mål og planer ændrer sig, men gem en kopi af ældre versioner (eller endnu bedre, opbevar dokumentet under versionskontrol), så du kan se, hvordan dit arbejde udvikler sig over tid.

Til sidst skal du gennemgå den tid og de ressourcer, som projektet vil kræve, og beslutte, om det er muligt at gennemføre dem. Hvis du ved, at du kun har en vis mængde tid til rådighed til projektet, skal du tage hensyn til det, og uanset hvad du gør, skal du ikke forpligte dig til en tidsfrist uden for projektet, selv om du er sikker på, at du kan nå den. OS-udvikling tager tid – meget tid – og det er ikke realistisk at forsøge at afslutte et komplet OS-projekt på et semester.

Valg af udviklingsmiljø

Du har brug for en platform til at udvikle dit nye system på. I overensstemmelse med tendenserne inden for generel databehandling er GNU/Linux det mest populære, men mange bruger også Windows. Udviklere, der bruger et GNU/Linux-system, har en lille fordel med hensyn til tilgængeligheden af værktøjer, men dette kan løses på Windows ved hjælp af et system som Cygwin eller MinGW.

• Binutils: Grundlæggende værktøjer til manipulation af objektfiler.
• GCC: GNU Compiler Collection. GCC indeholder bl.a. compilere til C, C++, Fortran og Ada.
• Make: Til automatisering af byggeprocessen, hvilket bliver virkelig nyttigt, når man har mere end en håndfuld filer.
• Grep og sed: Til at foretage mere kraftfulde søgninger og søge- og erstatninger (nyttigt, når du udfylder tabeller med data).
• Diffutils: Utroligt nyttige til at vise forskellene mellem to filer.
• Perl eller Python: Et af disse to scriptingsprog bør være installeret. Nyttige til bl.a. strengmanipulation. Perl plejede at være anbefalingen, men Python er nu ret modent og er muligvis lettere at lære. Begge har hundredvis af pakker/moduler til rådighed til at udføre forskellige opgaver.
• En assembler: For eksempel NASM eller GAS. Dette varierer afhængigt af din mål-CPU-arkitektur.
• En editor: Til at skrive dine assembler-, C- og andre (kode)filer.

Du bruger måske ikke alle disse værktøjer, men det er bedst at have dem ved hånden “for en sikkerheds skyld” og at vide, hvordan man bruger dem, selv på et grundlæggende niveau. Men hvis du har besluttet dig for at bruge et andet sprog, så er værktøjet for det meste op til dig, og måske vil ovenstående liste bare ikke hjælpe dig på nogen måde. Nedenfor er de oplysninger, der mest vedrører C/C++- eller Assembly-udviklere.

GNU/Linux

Det mest anbefalede system til OS-udvikling er GNU/Linux. Når du bruger GNU/Linux, er de fleste af GNU-udviklingsværktøjerne sandsynligvis allerede til stede. Hvis ikke, skal du bruge din distributions pakkehåndteringsværktøjer (APT, RPM, Portage, Pacman, Apk osv.) til at installere dem efter behov. Igen er det nødvendigt at lave en krydskompiler, så der ikke linkes i udviklingssystemets runtime-filer.

Fælles editorer er Vim, Emacs, KDevelop, Komodo Edit osv. Nogle foretrækker letvægtseditorer i stedet for et IDE, f.eks. gedit, Geany og SciTE. Mange kan lide Midnight Commander, som har en Text UI og en indbygget editor (mcedit) og derfor er ekstremt let og lynhurtig.

Om hvilke distributioner du bør bruge, kan du se listen over Linux-distributioner. De kom i alle former og størrelser, og ikke alle er egnede til kerneudvikling. Brug ikke en distro, der har et specifikt mål, som sikkerhed (Kali, Qubes, BackTrack, Parrot osv.), videnskabelige applikationer (f.eks. Scientific), firewalls og routing (f.eks. DD-WRT), systemgendannelse eller indlejrede miljøer (Knoppix, Rescatux, TinyCore) eller specifikt rettet mod begyndere (som Linux Mint, Nitrux osv.) Selv om en begyndervenlig Linux kunne gøre det, så vælg en, der er en distro til generelle formål. Brug også en distro, der har opdaterede pakker, bedst at vælge en, der bruger rolling-release. Debian er nem at bruge, men leverer ofte gamle, og lappede versioner (værktøjerne opfører sig måske ikke som beskrevet). Mange begyndere kan lide Ubuntu, hvilket er fint, men det rapporteres at have problemer med nogle værktøjskæder og kompileringsmiljøer (hvis du kompilerer din egen cross-compiler i stedet for at bruge en installeret, er dette ikke et problem).

De bedste distroer til kerneudvikling er (men husk at dette også er et spørgsmål om personlig smag, så disse distroer er ikke påkrævet snarere foreslået, og de kræver normalt en vis erfaring): Arch, Gentoo, Solus, Slackware, void osv. selv Puppy.

Hvis du er usikker, så prøv Ubuntu eller Manjaro.

Windows

For at få de nødvendige værktøjer, bør du installere Cygwin-miljøet. MinGW eller DJGPP er alternativer, men MSYS2 anbefales kraftigt, da det er det mest komplette og kompatible miljø, og det indeholder også en pakkehåndtering til at installere biblioteker og værktøjer.

Microsoft har for nylig (i skrivende stund) frigivet Windows Subsystem for Linux som en valgfri funktion til Windows 10. Det er i princippet en rigtig Ubuntu-kommandolinedistribution, der kører oven på Windows UDEN brug af en VM. De nyeste GCC og Binutils (6.1.0 og 2.27 i skrivende stund) kompilerer og fungerer korrekt i dette miljø. Ved hjælp af Bash-shell’en kan du få adgang til dine Windows-harddiske via /mnt/<drive letter>. Fordelen ved denne løsning er, at du kan arbejde med de Windows- eller Linux-værktøjer, du har brug for, uden at du behøver at finde ud af, om de virker i Cygwin. Mange af de nødvendige værktøjer kan installeres ved hjælp af “apt-get”.

For alle ovenstående anbefales det kraftigt at bygge en krydskompiler, ikke kun fordi standardkompileringerne er rettet mod forskellige eksekverbare formater, men fordi det generelt er en god idé. Se siden GCC Cross-Compiler for detaljer og instruktioner.

Du skal også bruge en editor. Det vil fungere at bruge Notepad, men det er nemmere, hvis du har en mere komplet editor. F.eks. bruges Notepad++ eller Notepad2 af mange mennesker. Hvis du er fortrolig med Unix-editorer, kan du vælge en af det udvalg, som Cygwin stiller til rådighed (som f.eks. omfatter Vim og Emacs, som kræver lidt tilvænning, men som er meget effektive).

Det er også muligt at bruge Visual Studio eller den frit downloadbare Visual C++ Express Edition til at skrive og kompilere dit styresystem. Du skal bruge en særlig konfigurationsfil, og du vil helt sikkert være i mindretal, men det fungerer ganske godt. Du kan endda installere Windows SDK ovenpå, hvilket muliggør 64 bit-udvikling. Den eneste faldgrube er, at dette ikke understøtter Inline Assembly.

Andre værktøjer som Watcom eller Borland kan også bruges, men de har hver især specifikke krav og er ikke meget udbredt til denne form for arbejde.

MacOS

Da det under motorhjelmen bruger FreeBSD’s userland, er det fuldt ud POSIX-kompatibelt. Alle de sædvanlige værktøjer er tilgængelige (vi, bash, dd, cat, sed, tar, cpio osv.) Næsten alle tutorials fungerer out-of-the-box. De manglende værktøjer er for det meste filsystemrelaterede: ingen loopback-enhed, ingen fdisk, ingen mkfs.vfat og heller ingen mtools. Men du kan bruge diskutil til disse formål, eller bruge brew eller macports til at installere de manglende værktøjer.

For at få gcc, plejede du at have en mpkg på 2nd Installation DVD’en til de ældre versioner. Nyere MacOS-versioner (10.13 og opefter) kan installere XCode på kommandolinjen (ikke IDE’en, kun værktøjskæden) ved at køre “xcode-select –install” fra en Terminal. Dette vil installere gcc, binutils og make. Denne gcc er faktisk en masquaraded CLang, men med nok funktioner til at bygge din egen cross-compiler uden problemer. Det er at foretrække at bruge den officielle compiler til at bootstrappe gcc frem for at installere en fra brew eller macports.

Test af dit styresystem

Hovedartikel: Test

Overstående artikel går meget i dybden med at vælge, hvordan du tester dit styresystem, og hvordan du integrerer det i din udviklingsproces. Både fysiske og emulerede testmiljøer bliver diskuteret.

Beskyttelse af din kode

Under din kodeopbygning vil du skrive hundredvis, ja tusindvis af kodelinjer. Du vil bruge et ubeskriveligt antal timer og sidde sent oppe om natten for at kode, når du egentlig burde gå i seng. Det sidste, du har brug for, er et disknedbrud eller en dårligt skrevet “rm”- eller “format”-kommando, der smider alt dit arbejde væk.

Det, du har brug for, er et versionsstyringssystem. CVS har været brugt i en række år, men har fået en del konkurrence fra Subversion, Bazaar, Mercurial og Git på det seneste. Hvis du har mulighed for det, bør du opsætte en fjerncomputer eller server som versionskontrolserver, men hvis du ikke har en sådan maskine til rådighed, kan du også hoste versionskontrolsystemet på din lokale udviklingscomputer. Du skal blot huske at tage backup af din kode på cd eller FTP en gang imellem.

Vi kan ikke understrege dette punkt stærkt nok: Hvis du ikke allerede bruger kildekontrol, bør du straks begynde at gøre det. Du behøver kun at lave en alvorlig fejl i din kode én gang for at indse, hvor vigtigt det er at have din kode sikkert versioneret og let at finde frem til. Selv om det kan virke som overkill for et lille, privat hobbyprojekt, vil du, når du først har vænnet dig til at bruge revisionskontrol, undre dig over, hvordan du nogensinde har kunnet undvære det.

For Git kan du oprette dit projekt på GitHub. Bitbucket er også et godt alternativ, da det understøtter både Git og Mercurial. Begge kommer med gratis, private repositories.

En yderligere fordel ved at bruge versionsstyring på et netværkstilgængeligt repository er, at det gør det meget nemmere at samarbejde med og få hjælp fra andre. Dette kan være ganske nyttigt, især i fora, da det kan undgå behovet for konstant at sende opdaterede versioner af din kode til en meddelelsestråd – du skal blot henvise samtalen til dit repository, og de andre i tråden vil have direkte adgang til dine mest aktuelle ændringer. Det er også afgørende, hvis du, efterhånden som projektet vokser, begynder at arbejde sammen med andre udviklere på projektet (du skal bare ikke forvente, at det sker fra den ene dag til den anden).

Fælles udgangspunkter

Den nemmeste måde at få en “hello world”-kerne i gang på er Bare Bones-tutorialen. En anden fremgangsmåde ville være at lære, hvordan selve computeren starter op, på siden Boot Sequence.

Der er også mange andre vejledninger til rådighed.

Opnå yderligere viden

Der er en utrolig mængde viden om udvikling af operativsystemer tilgængelig på internettet i dag. Det er bare et spørgsmål om at finde den. Først og fremmest er der selve denne wiki. Her er der bl.a. masser af Tutorials. Siden du er her, har du sikkert allerede fundet den. På denne side er der også forummet, hvor mange udviklere hænger ud og kan hjælpe dig (men sørg for at læse How To Ask Questions først). Der er skrevet en hel del bøger om udvikling af styresystemer. En række af disse findes på vores Bøger-side, og der er også flere ovre på osdever.net.

Se også

Artikler