Bedste svar
Det afhænger af, hvad du mener med operativsystemet. Jeg skrev engang et simpelt køsystem, der ville udføre flere protokolsessioner på en robin-måde. Men det kørte under et standardoperativsystem. Da mikrokontrollere først kom ud for indlejrede systemer, skrev ingeniører typisk deres eget rudimentære operativsystem som angivet i et af de andre svar.
Det mindste nyttige operativsystem, jeg har brugt, og som havde de grundlæggende funktioner i en multitasking, der fungerer hyldesystemet blev kaldt QNX. Det var et nedskåret Unix-system og kørte på den første IBM-pc. Det havde ingen fancy grafik, men jeg kunne komfortabelt lave softwareudvikling på det. Faktisk var den eneste reelle forskel for en moderne maskine brugergrænsefladen med farve og grafik. Så dybest set IBMs introduktion af DOS satte computerindustrien tilbage mindst 10 år. Der var en række overlegne operativsystemer rundt (som kunne have været tilpasset) eller udviklet på det tidspunkt med selvfølgelig Unix at sætte standarden.
Svar
Jeg er lige færdig med at udvikle en kerne til en klasse ( CS-4284 Systems & Networking Capstone ) i mit sidste semester i skolen. Tidligere tog jeg en OS-klasse, der har til formål at arbejde med operativsystemet fra programmørens perspektiv og ikke fra perspektivet af en OS-designer. At være involveret i OS og kerneudvikling i det sidste halvandet år (det er ikke i lang tid, men jeg har lært meget), her er hvad jeg anbefaler:
1. Master C Jeg kan ikke længere understrege dette. Nej, mestre det. OS-udvikling er hård. Det indeholder mange koncepter, som du virkelig har brug for for at mestre C, så det står ikke i vejen for dig. Tag f.eks. Unix-røret (indtastet | i en skal). For at udvikle et rør i dit operativsystem skal du forstå OS-filsystemet og filstrukturen rigtig godt. Det er et typisk problem med afgrænset buffer (forbruger / producent) og skal håndtere al synkronisering. Du skal være opmærksom på den virtuelle hukommelse, mens du skriver den. Desuden er Unix typisk BYOB (medbring din egen buffer). bliver nødt til at administrere bufferen korrekt, som brugeren har leveret osv … Den sidste ting, du gerne vil gøre her, er at håndtere grundlæggende C-problemer såsom pegepinde og hukommelsesadministration (Bemærk: hukommelsesadministration i operativsystemet er 10 gange sværere end C-hukommelsesadministration: du skal være opmærksom på bruger vs. kerne-adresserum)
2. Kernel vs. OS Du skal forstå forskellen mellem en kerne og et OS. En kerne er i det væsentlige operativsystemets hjerne. OS er et sæt applikationer, der er samlet sammen. F.eks. Inkluderer Mac OS X: en kerne, grænsefladen (GUI), indbyggede standardapplikationer (Finder – som bare er en abstraktion til visualiser filsystemet, TextEdit, en shell osv …)
3. Dyk ikke direkte ind Det er umuligt at starte laver kerneudvikling i løbet af få dage eller uger. Jeg foreslår, at du starter med følgende:
- Bliv fortrolig med GCC-kompileringstrin (hvad sker der, når du kører gcc, hvordan en eksekverbar produceres, og hvad sker, når du kører programmet). Du kan også skrive en simpel samler i C (tage samlingskode som input- og outputmaskinkode. Dette kræver, at du forstår, hvad .data-, .text- og .bss-sektioner er i samlingen (meget nyttigt nede vejen til at forstå OSs virtuelle hukommelse). Du vil også forstå adressering på maskinniveau og hvordan grene løses.
- Bliv fortrolig med mach værktøjer og programmer på niveau-niveau. Jeg foreslår at lave bombelaboratoriet, fordi der er mange undervisningsmaterialer derude til det. Bare google bomb lab.
- Bliv fortrolig med basale OS-angreb. Jeg foreslår at se på bufferoverløbet af samme grund som punkt 1 (google bufferoverløbslaboratorium).
- Lær om systemopkald, tråde og processer i C. Derefter udvikler du din egen shell i C.
- Lær om hukommelsesallokering, og implementer malloc og gratis i C. Lær om designkompromiser, allokeringsstrategier, frigørelsesstrategier osv …
- Lær om multi-threading og multi-processing i C. Derefter dykker du ned i synkroniseringsmekanismer (låse, mutexes, semaforer) og udvikler en trådpulje i C, som andre programmer kan bruge.
4. Nu kan du starte ægte, men forenklet OS-kerneudvikling På dette tidspunkt kan du begynde at udvikle på et ægte OS som OS-designer. Google Stanford Pintos, og du får adgang til en lille pædagogisk kerne udviklet i Stanford. Den leveres med dokumentation og et sæt på 4 projekter. Du kan google for nogle skoler, der har forelæsningsbilleder til Pintos. Jeg foreslår at købe operativsystemkoncepter ( Amazon.com: Operativsystemkoncepter (9781118063330): Abraham Silberschatz, Peter B.Galvin, Greg Gagne: Bøger ). Dokumentationen er ret god, og projekterne forklares godt. OS leveres også med tests, som du kan køre ved at køre make check, så du kan se, om du “har gjort tingene ordentligt eller ej.
5. Du kan begynde at bidrage til Linux Det vil kræve en stor indsats for at undersøge kildekoden og Linux-designbeslutninger (som er meget mere komplicerede end Pintos s), men jeg tror på dette tidspunkt vil du være i stand til i det mindste at starte. Med mere øvelse og læsning vil du kunne hente det.
Jeg har lige afsluttet trin # 4. Jeg elskede trin 1 til 3, men ærligt talt, halvvejs gennem 4, indså jeg, at jeg ikke er interesseret i OS-udvikling. Jeg kunne godt lide at arbejde med operativsystemet som programmerer (set fra et programmørs perspektiv), men nød ikke at grave dybere lige så meget. Jeg lærte dog meget af kerneudvikling, og det udsætter dig for mange ting. Desuden, hvis du kan skrive en kerne, skal du skrive noget stykke software derude. Jeg anbefaler kraftigt at gøre mindst de første 3 trin, da det giver dig god indsigt i OS. Du bliver bogstaveligt talt en bedre softwareingeniør generelt. Du lærer at værdsætte sprog på højt niveau mere og lære at bruge det rigtige værktøj / sprog / teknologi til det rigtige job.
Jeg har en masse materiale om OS-udvikling, projekter, tests osv … Hvis folk er interesserede, så lad mig det vide ved at kommentere, og jeg kan måske sammensætte en online e-bog / tutorial / guide med et testmiljø, der vil guide begyndere til OS-udvikling og give projekter og feedback at arbejde på.