Verbal algoritme til computerstartprocessen. Stadier af indlæsning af operativsystemer

En bootloader er et systemprogram, der udfører opstart. Mange læssere giver også bevægelse og sammenkobling. Nogle systemer adskiller sammenkædningsfunktionen fra flytte- og indlæsningsfunktionerne. Sammenkædning udføres af et specielt linkprogram (eller linkeditor), der flyttes og indlæses af loaderen.

Linking er sammenkædning af to eller flere separate oversatte programmer.

Flytning er ændring af et objektprogram, så det kan indlæses fra en anden adresse end den oprindelige.

Bootloader funktioner:

OP distribution;
flytte et program;
forbinder moduler;

OP distribution

Flytning af et program

Hvis der er adressekonstanter inde i modulerne, som er beregnet fra begyndelsen af modulet, så vil adresserne blive justeret i forhold til Basen.

Sammenkædning af moduler

Typer af bootloadere

Kompilere-run loadere

En af de mulige måder at udføre loader-funktionen på kan være at organisere assemblerens arbejde på en sådan måde, at assembleren, der arbejder i en del af hukommelsen, placerer maskininstruktioner og data, efterhånden som de samles direkte i de tildelte hukommelsesceller. for dem. Når kompileringen er færdig, overfører assembleren kontrollen til det resulterende programs indgangspunkt. Dette er en meget enkel løsning, der giver dig mulighed for at undvære yderligere procedurer. Dette skema kaldes "compile-execute", og "loader" består af en enkelt instruktion, der overfører kontrol til det samlede program.

Absolute loaders er nemme at implementere, men har en række funktioner:

opgaven med at distribuere OP'en udføres af programmøren (ved at bruge direktivet til at indstille den oprindelige værdi af OP'en);
opgaven med at flytte programmet udføres af compileren;
sammenkobling af moduler - bestemt af programmøren (ring 600);
indlæse programmer i OP og lancere dem til udførelse.

Fordele:

mindre bootloader-størrelse (hukommelsesstørrelse);
adskillelse af kompilerings- og indlæsningsfaserne, hvilket reducerer tiden til behandling af moduler;
muligheden for at bruge flere programmeringssprog, pga strukturerne af de oprettede objektmoduler er identiske.

Fejl:

En stor mængde arbejde falder på programmøren. Det er nødvendigt konstant at overvåge ændringer i startadresser ved modifikation af moduler, fordi deres længde ændres.

Absolut Loader Objekt Filstruktur

Informationsjournalen består af:

skilt;
absolut adresse på det OP, hvor oplysninger kan overføres;
antal informationsbytes i meddelelsen;
bytes af information;
kontrolsummer;
nummerering.

Kontrolposten består af:

skilt;
indgangsstedsadresse.

En simpel absolut loader virker:

Kontroller, om der er nok hukommelse til dette program (se den første post).
Sekventiel læsning af programteksten og placering på den angivne adresse.
Overførsel af kontrol til adressen for programafvikling.

Tuning bootloader

For at undgå behovet for at samle alle underrutiner igen, når der foretages en ændring af en af dem, og også for at frigøre programmøren fra opgaverne med hukommelsesallokering og kommunikation af underrutiner, blev der udviklet såkaldte loadere. Denne bootloader tillader et program at have flere programsegmenter og et datasegment (fælles segment). Samleren oversætter hvert segment separat og forsyner læsseren med tekst og information om bevægelser og krydsreferencer mellem segmenter.

Outputtet fra assembleren med dette skema er objektprogrammet og information om alle andre programmer, som der er kald til i dette program. Derudover er der information om de steder, der skal ændres under lastning (bevægelsesoplysninger), dvs. om celler, hvis indhold afhænger af programmets placering i hukommelsen.

For hvert kildeprogram producerer assembleren tekst (oversættelsesresultat) som outputinformation, efterfulgt af en overgangsvektor, der indeholder adresserne på navnene på underrutiner, der tilgås i kildeprogrammet. For eksempel, hvis SQRT-rutinen er den første rutine, der kaldes, vil den første celle i springvektoren indeholde det symbolske navn SQRT. Udsagn, der indeholder et kald til en SQRT-rutine, vil blive oversat til en springinstruktion, der angiver adressen på det grenvektorelement, der er knyttet til SQRT'en. Samleren vil også formidle yderligere information såsom den samlede længde af programmet og længden af grenvektoren. Efter indlæsning af programteksten og springvektoren i hukommelsen, indlæser loaderen hver rutine specificeret i vektoren. Derefter vil han placere en kommando for at gå til den tilsvarende subrutine i hvert element i vektoren. Kaldning af SQRT-underrutinen vil således resultere i udførelse af en hopkommando til den første celle i overgangsvektoren, som vil indeholde en hopkommando til den kaldte underrutine.

Denne indlæsningsordning med to-trins kontroloverførsel bruges ofte i computere med et fast instruktionsformat og direkte adressering.

Denne bootloader har en række ulemper:

overgangsvektoren er ikke helt bekvem til at indlæse og gemme eksterne data (placeret i et andet programsegment);
overgangsvektoren øger længden af objektprogrammet;
Indlæseren opererer på programsegmenter, men letter ikke adgang til datasegmenter, der kan deles af flere rutiner.

Direkte linkende bootloader

Den direkte linkende bootloader giver mest mulighed for at flytte programmer og data i hukommelsen og er i øjeblikket den mest almindelige. En sådan loader har den fordel, at den tillader brugen af et stort antal af både programsegmenter og datasegmenter og giver programmøren fuldstændig frihed til at få adgang til data, der er placeret i andre segmenter, samtidig med at den tillader separat oversættelse.

Samleren (oversætteren) skal videregive følgende information til bootloaderen med hvert program og datasegment:

segmentlængde;
en liste over alle segmentsymboler, der kan tilgås fra andre segmenter, og deres relative adresser;
en liste over alle symboler, der ikke er defineret i dette segment, som er tilgået i dette segment;
oplysninger om placeringen af adressekonstanter i segmentet og en beskrivelse af, hvordan deres værdier skal ændres;
maskinkoder som følge af oversættelse og tildelte relative adresser.

En af ulemperne ved en direkte link-indlæser i sin enkleste form er, at hver gang programmet udføres, skal det gentagne gange udføre funktionerne hukommelsesallokering, flytte, linke og indlæse alle nødvendige underrutiner. Disse problemer kan løses ved at udføre indlæsningen ved hjælp af to separate programmer: kombinereren og modulindlæseren. Kombinerens output er et sæt data i et format, der tillader programmet at blive indlæst i hukommelsen, og kaldes et load-modul. Der findes flere typer kombinatorer. En af dem er den såkaldte link-editor, som gemmer den information, der er nødvendig for at flytte modulet i hukommelsen, så modulet som helhed derefter kan konfigureres og indlæses på en vilkårlig hukommelsesplacering. I dette tilfælde skal modulindlæseren udføre hukommelsesallokering og -flytningsfunktioner, men forbliver fri for den komplekse opgave at forbinde objektmoduler og underrutiner.

Dynamisk læsser

I hvert af de overvejede skemaer blev det antaget, at alle de nødvendige rutiner blev indlæst i hukommelsen samtidigt. Hvis den samlede mængde hukommelse, der kræves af rutinerne, er mindre end maskinens tilgængelige hukommelse, opstår der problemer. Disse vanskeligheder overvindes ved at bruge et dynamisk læsseskema med sekventiel brug af en kombinerer og en læsser. Denne ordning er baseret på, at der normalt kræves forskellige rutiner på forskellige tidspunkter og kan udelukke hinanden. Ved eksplicit at definere, hvilken subrutine der indeholder opkald til andre subrutiner, kan du definere en såkaldt overlay-struktur, der specificerer gensidigt eksklusive subrutiner.

Ladningsmodulet er dannet. Det er flytbart og skal have flyttebord. Desuden skal opbygningen af lastmodulet indeholde oplysninger om forbindelser. Indlæseren skal indeholde en sådan del som en overlay-manager; den vælger fra opstartsmodulerne præcis dem, der starter, og organiserer under arbejdet indlæsningen af de nødvendige moduler i OP.

Dynamisk linking

Der er tilfælde, hvor subrutiner er dynamisk forbundet under programafvikling for at sikre effektiv brug af maskinens hukommelse. Det vil sige, at subrutiner kun indlæses i hukommelsen, som de kaldes. Dette kan være en fordel, fordi... Under visse forhold i programmet er nogle underrutiner muligvis slet ikke nødvendige. Lad os se på et eksempel:

hvis (betingelse 1)
subrutineopkald 1
hvis (betingelse 2)
subrutineopkald 2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
hvis (betingelse m)
opkald subrutine m

Mange af grenene vil blive sprunget over, og det vil ikke være nødvendigt at indlæse i OP'en, for eksempel subrutine 2, hvis betingelse 2 ikke er opfyldt. I dette tilfælde skal loaderen arbejde samtidigt med programmet og udføre funktionerne til at linke og indlæsning af underrutiner.

Send dit gode arbejde i videnbasen er enkel. Brug formularen nedenfor

Studerende, kandidatstuderende, unge forskere, der bruger videnbasen i deres studier og arbejde, vil være dig meget taknemmelig.

Volga Universitet opkaldt efter V.N. Tatishchev

Fakultet for Datalogi og Telekommunikation

Institut for "Informatik og Kontrolsystemer"

KURSUSARBEJDE

disciplin: "Systemsoftware"

Emne: " Loader”

Udføres af en elev. IS-303

Krasnoseltsev I. P.

Lærer: Trubacheva S.I.

Tolyatti

Introduktion

1. Teoretisk del

2. Designdel

2.1 Problemstilling

2.2 Udvikling af en algoritme til løsning af problemet

2.3 Beskrivelse af applikationsprogrammets indlæsningsalgoritme

2.4 Beskrivelse af OS boot-algoritmen

2.5 Beskrivelse af Unix boot-algoritmen ved hjælp af LILO boot loader

Konklusion

Referencer

Introduktion

Relevansen af mit kursusarbejde ligger i, at udviklingen af computere og deres styresystemer gik parallelt med udviklingen af forskellige bootloader-programmer. Visse operativsystemer kræver forskellige bootloadere for at starte. For eksempel kræver Unix multi-user operativsystemet en LILO boot loader og forskellige hjælpeprogrammer. Enhver indlæsning af operativsystemet påvirker RAM, som bruges af både de primære og sekundære bootloadere. Under indlæsning opstår der forskellige typer fejl, som bootloaderen omgår eller fuldfører indlæsningsprocessen (viser en informativ meddelelse).

En bootloader er et program, som mere end én computer og mere end ét operativsystem simpelthen ikke kan undvære.

1 . Teoretisk del

Microsoft OS opstartsproces

Uanset hvilket operativsystem vi overvejer, skal det indlæses i RAM for at OS kan begynde at styre computeren. Lad os derfor se på, hvordan processen med at indlæse forskellige OS'er foregår. Da vi kun er interesseret i at starte fra harddiske, vil vi ikke overveje funktionerne ved at starte fra en diskette, cd-rom og over netværket. Lad os starte med MS-DOS og MS Windows.

Som du ved, kører POST-programmet (Power On Self Test) først, når du tænder for din computer. Den bestemmer mængden af tilgængelig hukommelse, tester den, bestemmer tilstedeværelsen af andre komponenter (tastatur, harddisk osv.) og initialiserer adapterkort. Meddelelser vises normalt på skærmen om mængden af hukommelse, om dens testning, en liste over registrerede enheder (diskette og harddiske, processor, COM-porte osv.).

Efter at testen er fuldført, kalder POST Int 19h, som forsøger at finde en bootenhed. Søgningen udføres i den rækkefølge, der er defineret i Setup BIOS, og udføres ved at polle nul-sektorerne for de tilsvarende enheder. Hvis disken er bootbar, er der i dens nulsektor en master boot record - Master Boot Record (MBR). De sidste to bytes af MBR er et "magisk tal", hvilket er et tegn på, at denne sektor er en MBR, og derfor er disken bootbar. Ud over det "magiske nummer" indeholder MBR en diskpartitionstabel, som allerede blev nævnt ovenfor, og et lille program - den primære bootloader, med et volumen på kun 446 (0 * 1BE) bytes.

Tabel 2.1 viser strukturen af den primære opstartssektor, der blev oprettet under installationen af Windows.

Tabel 2.1 Struktur af hovedstøvlesektoren

Interrupt 19h BIOS indlæser den primære bootloader i computerens hukommelse og overfører kontrol til dette program. Men sådan et lille program kan ikke starte OS; alt det kan gøre er at indlæse et mere kraftfuldt program i hukommelsen - en sekundær bootloader.

For at gøre dette søger den i partitionstabellen efter den aktive partition og læser den sekundære bootloader ind i hukommelsen, som er placeret fra den første logiske sektor i den aktive partition. Læg mærke til ordet "begyndelse". Faktum er, at den sekundære bootloader i forskellige systemer har forskellige længder.

Den sekundære bootloader indlæser det første lag af programmer, der er nødvendige for at køre OS. I tilfælde af MS - DOS indlæser bootprogrammet IO.SYS på adressen 700h, derefter MSDOS.SYS og overfører kontrol til SYSINIT-sektionen af IO.SYS-modulet.

Hvis der af en eller anden grund ikke findes nogen aktiv partition på disken, fortsætter opstartsprocessen ved at behandle interrupt 18h. Denne gren bruges sjældent i sin helhed, men denne funktion kan være meget nyttig i nogle situationer. Under fjernopstart, når operativsystemet indlæses fra serveren, omdirigeres denne afbrydelse af POST-programmet til ROM'en på netværkskortet.

Problemer med store diske

I MS-DOS og de første versioner af Windows blev adgangen til diske organiseret gennem interrupt 13 (Int 13h) i BIOS. I dette tilfælde blev adresseringssektorer på disken brugt baseret på angivelse af numrene på cylinder, hoved og sektor på sporet (C/H/S). Mere præcist:

1)AH - valg af drift;

2)CP - lavordens 8 bits af cylindernummeret;

3)CL - bit 7-6 svarer til de mest signifikante bit af cylindernummeret, bit 5-0 svarer til sektornummer;

4)DH - læsehovednummer;

5)DL - disknummer (80h eller 81h).

Det skal bemærkes, at alle de ovennævnte begrænsninger kun er væsentlige på OS-startstadiet, da Linux selv og de nyeste versioner af Windows ikke længere bruger BIOS interrupt 13, når de arbejder med diske, men bruger deres egne drivere til at arbejde med diske. Men før systemet kan bruge sin egen driver, skal det i det mindste indlæse den. Derfor er ethvert system tvunget til at bruge BIOS i den indledende opstartsfase. Dette medfører restriktioner for at placere mange systemer ud over 8 GB; de kan ikke starte derfra, selvom de efter en vellykket opstart kan arbejde med meget større diske. For at forstå, hvordan vi kan komme uden om disse begrænsninger, har vi brug for noget viden om, hvordan Linux OS starter.

LILO boot loader fra Linux OS distribution

Før du begynder at installere det andet OS, skal du vælge en metode til at organisere OS-valget på computerens startstadium. Loader-programmer løser dette problem. Der er flere programmer af denne art. Da vi taler om Linux, er den første ting, vi skal nævne, LILO-programmet, som er inkluderet i enhver Linux-distribution.

LILO er et sæt af flere programmer: selve bootloaderen, programmer, der bruges til at installere og konfigurere bootloaderen, og servicefiler:

/sbin/lilo-programmet, som kører under Linux, tjener til at skrive alle nødvendige oplysninger under opstartsfasen til de relevante steder. Den skal genstartes hver gang der foretages en ændring af kernen eller LILO-konfigurationsfilen;

Forskellige servicefiler, som LILO har brug for under opstart. Disse filer er normalt placeret i /boot-mappen. De vigtigste af dem er selve bootloaderen og kortfilen (/boot/map), som angiver placeringen af kernen. En anden vigtig fil er LILO-konfigurationsfilen, som normalt hedder /etc/lilo.conf;

Selve bootloaderen er den del af LILO, der først indlæses i hukommelsen gennem en BIOS-afbrydelse, og som indlæser Linux-kernen eller opstartssektoren i et andet OS. Bootloaderen består også af to dele. Den første del skriver til boot-sektoren og bruges til at indlæse den anden del, som er meget større i størrelse. Begge dele er normalt gemt på disken i filen /boot/boot.b.

Ved installation af systemet kan LILO-startsektoren placeres følgende steder:

Opstartssektoren for disketten i Linux-format(/dev/fd0,...);

MBR på den første harddisk (/dev/had, /dev/sda,...);

Opstartssektoren for den primære partition af Linux-filsystemet på den første harddisk (/dev/hda1, /dev/hda2,...);

Opstartssektoren for den logiske partition i den udvidede partition på den første harddisk (/dev/hda5,...). Sandt nok, de fleste programmer som fdisk antager ikke, at du kan starte fra en udvidet partition og nægter at erklære den aktiv. Derfor inkluderer LILO et særligt program (aktiver), der giver dig mulighed for at omgå denne begrænsning. Men fdisk-programmet fra Linux-distributionen understøtter muligheden for at aktivere en udvidet partition. For at gøre dette skal du bruge enten -b-indstillingen eller BOOT-variablen.

LILO-startsektoren kan ikke placeres på følgende steder:

Opstartssektoren for en diskette eller primær partition, formateret i andre filsystemer;

I Linux swap-partitionen;

Ud over det faktum, at LILO også har brug for følgende filer under indlæsning:

-/boot/map (oprettet når du kører /sbin/lilo);

Alle downloadbare kerneversioner (hvis du vælger en kerneversion under downloadfasen);

Bootsektorer af andre operativsystemer, der vil starte via LILO;

Meddelelser udstedt under indlæsning (hvis defineret)

Når LILO starter op, vises ordet "LILO". I dette tilfælde angiver outputtet af hvert bogstav fuldførelsen af en bestemt handling eller fase af indlæsning af LILO. Hvis overførslen mislykkes, kan du ud fra antallet af viste bogstaver bedømme årsagen til problemet.

Intet udlæses - ingen del af LILO blev indlæst. Enten blev LILO ikke installeret, eller også er den partition, den er på, ikke aktiv

L [fejlkode] - den primære læsser blev indlæst og startet (kontrol blev overført til den), men den var ikke i stand til at indlæse den sekundære læsser. En tocifret fejlkode angiver den specifikke årsag til problemet. Dette skyldes normalt mediefejl eller forkert diskgeometri. Medmindre LILO stopper på dette tidspunkt og smider en endeløs række af fejlkoder, er problemet normalt nemt at løse.

LI - den primære loader var i stand til at indlæse den sekundære loader, men var ikke i stand til at starte den til udførelse. Dette kan være forårsaget af en fejl i indstilling af diskens geometri eller fordi /boot/boot.b blev flyttet uden at genstarte /sbin/lilo.

LIL - den sekundære loader startede, men kunne ikke starte deskriptortabellen fra kortfilen. Årsagen er normalt tilstedeværelsen af defekter på disken eller forkert specificeret diskgeometri.

LIL? - den sekundære bootloader blev indlæst til den forkerte adresse. Typisk forårsaget af en fejl i indstilling af diskens geometri eller fordi /boot/boot.b blev flyttet uden at genstarte /sbin/lilo.

LIL- - deskriptor tabel ødelagt. Typisk forårsaget af en fejl i indstilling af diskens geometri eller fordi /boot/boot.b blev flyttet uden at genstarte /sbin/lilo.

LILO - alle dele af LILO er blevet indlæst.

Init-processen og filen /etc/inittab

Som du ved, efter at have tændt for computeren og gennemført hardwaretest, læses BIOS'en fra den første sektor af boot-disken, som er bootloader-programmet. Dette program starter hovedsystemets opstartsindlæser (for eksempel LILO), som igen indlæser systemkernen i hukommelsen, som normalt er gemt i filen vmlinuz-x.y.z-a i /boot-mappen.

Umiddelbart efter opstart monterer kernen rodfilsystemet og starter init-processen. Init-processen er det program, der er ansvarligt for at fortsætte opstartsproceduren og overføre systemet fra den initiale tilstand, der opstår efter kernen-boots, til standardtilstanden for behandling af anmodninger fra mange brugere.

Den nøjagtige liste over disse operationer afhænger af det såkaldte kørselsniveau. Udførelsesniveauet bestemmer listen over handlinger udført af init-processen og systemets tilstand efter boot, dvs. konfiguration af kørende processer. Runlevel er identificeret med et enkelt symbol. Der er 8 hovedudførelsesniveauer i Linux OS:

1) Systemstop;

2) Enkeltbrugertilstand (til særlige administrationssager);

3)Multi-user mode uden NFS (det samme som 3, hvis computeren ikke fungerer med netværket);

4) Fuld multi-user mode;

5)Brug er ikke reguleret;

6) Anvendes typisk til at køre systemet i grafisk tilstand;

S) (eller s) - nogenlunde det samme som enkeltbrugertilstand, men S og s bruges hovedsageligt i scripts.

Det første init-processen gør efter start er at læse dens konfigurationsfil /etc/inittab. Denne fil består af individuelle linjer. Hvis en linje begynder med et # eller er tom, ignoreres den. Alle andre linjer består af 4 felter adskilt af koloner:

id : løbeniveauer : handling : behandle

id - rækkeidentifikator;

runlevels - run levels;

proces - proces;

handling - handling;

Handlingsfeltet indeholder et nøgleord, der definerer yderligere betingelser for kommandoen angivet af procesfeltet. Gyldige værdier for handlingsfeltet:

respawn - genstart processen, hvis den afsluttes;

én gang - udfør kun processen én gang, når du flytter til det angivne niveau;

vent - processen vil blive lanceret én gang, når du flytter til det angivne niveau;

sysinit - Dette nøgleord angiver handlinger, der udføres under systemopstartsprocessen, uanset kørselsniveauet (id-feltet ignoreres).

boot - processen vil blive lanceret på systemets opstartsstadium fra kørselsniveauet;

bootwait - processen vil blive startet på systemets opstartsstadium fra kørselsniveauet, og init vil vente på dens afslutning;

initdefault - linjen, hvor dette ord vises i handlingsfeltet, bestemmer det eksekveringsniveau, som systemet går til som standard.

off - ignorer dette element;

powerwait - Tillader init-processen at stoppe systemet, når strømmen går tabt.

Ctrlaltdel - tillader init at genstarte systemet, når brugeren trykker på en tastekombination ~~på tastaturet.~~

Denne liste er ikke udtømmende. Mere information om inittab-filen kan findes på man-siderne init(8), inittab(5) og getty(8).

2 . Projektdel

2.1 Problemstilling

Det er nødvendigt at studere teoretisk materiale om det valgte emne, udvikle en algoritme, som læsseren kan betjene, når metoden implementeres (til stede i form af et blokdiagram) og beskrive algoritmen.

2.2 Udvikling af en algoritme til løsning af problemet

Input: Single-processor system, applikationsprogram, LILO boot loader, POST program, gensidig udelukkelse.

Figur 1 viser algoritmen "indlæsning af applikationsprogram".

Figur 2 viser algoritmen til "indlæsning af operativsystemet"

2.3 Beskrivelse af applikationsprogrammets indlæsningsalgoritme

1) Applikationsprogrammet startes til udførelse. Herefter aktiveres systemprogrammet "Bootloader".

2) Efter aktivering begynder scanning af RAM for at finde ledige områder.

3) Hvis sådanne områder findes, så begynder bestemmelsen af begyndelsen af lokationsadressen for det frie område. Så går vi til denne adresse og bestemmer størrelsen af det frie område.

4) Bagefter bestemmes størrelsen af koden for det applikationsprogram, der startes til afvikling.

5) Sammenlign størrelsen af koden og størrelsen af det frie område i RAM.

6) Hvis der er nok plads i RAM til at kopiere applikationsprogramkoden, så er de virtuelle sidetal på de fysiske sider sat i sidetabellen. Derefter kopieres applikationsprogramkoden til RAM. Og færdiggørelse af processen.

7) Ellers finder vi ud af, om der er plads nok i RAM til en del af applikationsprogramkoden. Hvis det er tilfældet, gentager vi disse trin, når der er plads nok til den komplette kode for applikationsprogrammet. Men efter kopiering af koden til RAM, kopieres en del af koden ind i bytteområdet.

8) Hvis der ikke er plads nok til en del af koden, så sker overgangen til stadiet med scanning af RAM for at finde ledige områder.

2.4 Beskrivelse af OS-indlæsningsalgoritmen (operativsystem)

1) POST-programmet starter. Dette program tester tilgængelig hukommelse, bestemmer tilstedeværelsen af andre komponenter (forskellige pc-enheder, for eksempel: tastatur, harddisk osv.) og initialiserer adapterkort.

2) Efter at POST-programmet er kørt, vises resultaterne af dets arbejde på skærmen.

3) Kald 19H-programmet, som forsøger at finde opstartsenheden.

4) Interrupt 19H BIOS indlæser den primære boot loader i computerens hukommelse og overfører kontrol til dette program

5) Indlæs operativsystemet på grund af manglen på kraft i dette program. Hun leder derfor efter et mere kraftfuldt program, der er i stand til dette - en sekundær bootloader. For at gøre dette søger den i partitionstabellen efter den aktive partition og læser den sekundære bootloader ind i hukommelsen.

6) Den sekundære opstartsindlæser indlæser det første lag af programmer, der er nødvendige for at køre OS. Bootloader-programmet indlæser IO.SYS-modulet på adresse 700h, hvorefter MSDOS.SYS overfører kontrol til SYSINIT-sektionen af IO.SYS-modulet.

7) Hvis den aktive partition i partitionstabellen af en eller anden grund ikke blev fundet på disken, fortsætter opstartsprocessen ved at behandle 18-timers afbrydelsen.

2.5 Beskrivelse af indlæsningsalgoritmenUnixved hjælp af bootloaderLILO

1) Kør /sbin/lilo-programmet for at skrive alle de nødvendige oplysninger under opstartsfasen til de relevante steder. Søg efter servicefiler, der kræves af LILO under opstart.

2) Hvis filerne ikke findes, vises en meddelelse, der angiver slutningen af overførslen.

4) Hvis den primære læsser ikke var i stand til at indlæse den sekundære læsser, vises en informationsmeddelelse, der angiver en fejl under lastning, på skærmen.

6) Hvis den primære loader indlæste den sekundære, men ikke kunne starte, vises en informationsmeddelelse om en fejl under indlæsning.

7) Ellers startes den sekundære bootloader.

8) Kontroller, at den sekundære bootloader er indlæst til den korrekte adresse.

9) Hvis ikke, så vises en informationsmeddelelse om fejl under indlæsning.

10) Kontrol af om deskriptortabellen er ødelagt. Hvis ja, så vises en informationsmeddelelse om en fejl under indlæsning. Og hvis ikke, så indlæses deskriptortabellen fra kortfilen.

11) Kontrol af, om lanceringen af deskriptortabellen var vellykket. Hvis ikke, vises en informationsmeddelelse om en fejl ved opstart.

12) Vis ellers en informationsmeddelelse om vellykket indlæsning af LILO.

Konklusion

Dette kursusarbejde undersøger nogle aspekter af indlæsning af programmer. Typer af læssere: bevægelige, primære, sekundære osv. Nødvendigheden af at bruge bootloaderen i forskellige driftsmiljøer er blevet bevist. Forskellige opstartsmetoder er dækket, såsom programopstart, LILO-opstart og OS-opstart. Teoretisk materiale om emnet er blevet undersøgt, algoritmer til betjening af læsseren ved implementering af metoden er blevet udviklet (præsenteret i form af et blokdiagram).

Referencer

1. Tanenbaum Andrew. Moderne operativsystemer / Andrew Tanenbaum. - 2. udg. - Sankt Petersborg: Peter, 2002. - 1037 s.: ill. - (Classics of Computer Science). - ISBN 5-318-00299-4

2. Partyka, T.L. Operativsystemer, miljøer og skaller: En vejledning til miljøer. Prof. Arr. rec. MO / Partyka, T.L., Popov, I.I. - M.: FORUM: INFRA - M, 2006. - 399 s.: ill. - (Faglig uddannelse). - ISBN 5-8199-0072-5-16-001355-5

3. Olifer, V.G. Netværksoperativsystemer: Lærebog. manual for universiteter MO / Olifer, V.G., Olifer, N.A. - Sankt Petersborg: Peter, 2003. - 538 s.: ill. - ISBN 5-272-00120-6

4. Trubacheva, S.I. Programmering i operativsystemer: Metodisk manual / Trubacheva, S.I. - Tolyatti: VUiT, 2006. - 44 s.

5. Terence Chan. Systemprogrammering i C++ til Unix / Ed. Kolomytseva. - Kiev, 2004.

6. Tacket D., Barnett S. Specialudgave. Brug af LINUX / Transl. fra engelsk - 4. udg. St. Petersborg: Williams, 2003.

7. Ivanova G.S. Programmering i SI++ / Lærebog. Ed. M.: MSTU, 2002.

Lignende dokumenter

Generelle egenskaber ved Android-systemet, gennemgang af dets analoger. Nødvendige komponenter for at komme i gang i Android. Opsætning af Ubuntu-konfigurationer. Skrivning af scripts for at forenkle Linux-generering. Fejlretning og test af programmet på freescale i.MX53-kortet.

kursusarbejde, tilføjet 10/12/2012

Overvejelse af egenskaberne ved boot managers. Beskrivelse af Download Accelerator Plus, Download Master, FlashGet, GetRight, ReGet, Go!Zilla. Sammenlignende egenskaber for Windows boot managers. Programmer til Unix, Linux og Mac-operativsystemer.

abstract, tilføjet 09/06/2014

Konceptet og strukturen af Linux-operativsystemdistributioner, historien om deres oprindelse og de vigtigste udviklere. Klassificering af distributioner efter arten af montering og installation, ændring af deres færdige versioner. Beskrivelse af måder at oprette din egen distribution på.

kursusarbejde, tilføjet 04/02/2014

Generelt diagram over læsseprocessen, dens hovedstadier og karakteristiske træk. Primære og sekundære læssere, deres funktionalitet og handlingsretninger. Pladser til eventuel placering af støvlesektoren. Krav til diskplads.

præsentation, tilføjet 20.12.2013

Analyse af de tekniske muligheder i Mandriva Linux-operativsystemet - en GNU/Linux-distribution udviklet af det franske firma Mandriva, som producerer gratis, kommercielle og virksomhedsversioner af sin distribution. Linux shell installationstrin.

præsentation, tilføjet 23/05/2010

Højdepunkter fra historien om operativsystemer, der forbinder hardware og applikationsprogrammer. Karakteristika for Microsoft Windows Seven-operativsystemet, analyse af Linux-operativsystemet. Fordele og ulemper ved hvert operativsystem.

kursusarbejde, tilføjet 05/07/2011

Valg af værktøjer til udvikling af etm. Implementering af et modul til Gentoo distributionen, der fungerer i henhold til brugermanualen til dette system. Test af installationsprogrammet på forskellige arkitekturer.

afhandling, tilføjet 18.07.2013

Stadier af indlæsning af et Linux-system, registrering. Brugerkontostyring. Princippet om navngivning af enheder, formålet og brugen af specielle filer. Håndtering af filer, adgang til filsystemet, opgaver. Grundlæggende Linux-filstruktur.

træningsmanual, tilføjet 15.11.2014

Overvejelse af forskellige operativsystemdistributioner. Undersøgelse af dataudvekslingsprotokoller og fysiske datalagringsformater. Udvikling af en distribution baseret på Linux-operativsystemet til drift som en del af StarNAS netværkslager.

kursusarbejde, tilføjet 11/05/2015

Funktioner ved at indlæse Linux-operativsystemet i terminaltilstand, logge på og registrere brugere. Udfører filomfordeling og bruger den til at arbejde med operativsystemkommandoer. Anvendelse af softwarekanaler (transportører).

Operativsystemet er gemt i ekstern hukommelse, normalt på en harddisk, sjældnere på en diskette. For normal drift af en computer er det nødvendigt, at styresystemets hovedmoduler er i RAM. Derfor, efter at have tændt for computeren, bliver operativsystemet automatisk omskrevet (indlæst) fra disken til RAM. De vigtigste aspekter af denne belastning er afbildet i form af en algoritme i fig. 9.13.

Ris. 9.13. Algoritme til at indlæse operativsystemet fra disk til RAM

Når du har tændt for computeren, ser du tallene ændre sig på skærmen. Disse tal afspejler processen med at teste RAM af BIOS-programmet. Hvis der opdages en fejl i RAM-cellerne, vises en meddelelse.

Når hardwaretestningen er gennemført, får du adgang til drevet med diskette A, og indikatorlampen ved siden af lyser. Hvis du indlæser operativsystemet fra en diskette, skal du før eller under test indsætte systemdisken i drev A. Ellers, hvis der ikke er noget operativsystem på disk A, tilgås harddisken, som det fremgår af indikatoren lys ved siden af.

Indlæsning i RAM'en for den 0. sektor på den 0. side af disken, hvor bootloaderen er placeret (BOOT RECORD) begynder. Styringen overføres til bootloaderen, som kontrollerer tilstedeværelsen af IO.SYS-udvidelsesmodulet og MSDOS.SYS-basismodulet på systemdisken. Hvis de er på deres anviste plads (cm. ris. 9.10), så indlæser den dem i RAM, ellers vil der blive vist en besked om deres fravær. I dette tilfælde anbefales det at downloade igen. Genstartsignalet overfører kontrollen til det permanente BIOS-modul, som igen skriver boot-blokken fra disken ind i RAM osv.

Husk! Til genstart operativsystemet tryk på tasterne samtidigt i hukommelsen .

Efter vellykket indlæsning af IO.SYS-udvidelsesmodulet og MSDOS.SYS-basismodulet i RAM, indlæses COMMAND.COM-kommandoprocessoren, og CONFIG.SYS-konfigurationsfilen behandles, som indeholder kommandoer til tilslutning af de nødvendige drivere. Denne fil kan mangle, hvis du er tilfreds med basisversionen af operativsystemet.

Batchfilen AUTOEXEC.BAT behandles derefter. Ved hjælp af denne fil kan du konfigurere driftsmiljøparametrene. Opret for eksempel en virtuel disk, skift udskrivningstilstande, indlæs hjælpeprogrammer osv.

Opmærksomhed! Filer med filtypenavnet .BAT spiller en særlig rolle, når du arbejder i et systemmiljø. De indeholder et sæt operativsystemkommandoer eller eksekverbare filnavne. Efter at have kørt en fil med filtypenavnet .BAT, udføres alle kommandoer, der er skrevet i den, automatisk en efter en.

En fil med standardnavnet AUTOEXEC.BAT adskiller sig fra andre filer af typen .BAT ved, at udførelsen af kommandoer, der er placeret i den, begynder automatisk umiddelbart efter, at operativsystemet er startet.

Hvis filen AUTOEXEC.BAT mangler, bliver du bedt om at indtaste dato og klokkeslæt:

hvis du trykker på enter-tasten, accepteres de såkaldte systemparametre bestemt af computertimeren som den aktuelle dato og klokkeslæt;

Hvis du vil nulstille systemets dato og klokkeslæt, skal du som svar på prompten indtaste værdierne i en af de medfølgende formularer, for eksempel:

25-10-1997 (måned dag år)

7:30:10.00r (timer:minutter:sekunder)

Når AUTOEXEC.BAT-filen er færdig med at køre, og hvis denne fil ikke findes, vil en systemdiskprompt blive vist på skærmen, f.eks. C:\>. Dette indikerer, at opstartsprocessen er fuldført normalt, og du kan begynde at arbejde ved at indtaste applikationsnavnet eller operativsystemkommandoen.

Bemærk. Filerne CONFIG.SYS og AUTOEXEC.BAT mangler muligvis. I dette tilfælde vil driftsmiljøindstillingerne blive sat til standard.

Husk! Harddisken skal permanent lagre operativsystemet.

Når du tænder for din computer, skal alle diskettedrev være åbne.

Disketten med applikationsprogrammer skal indsættes i drevet, efter at overførslen er fuldført.

TEKNOLOGI TIL ARBEJDE I MS DOS

§ Oversigt over kommandoer

§ Grundlæggende kommandoer til at arbejde med mapper

§ Grundlæggende kommandoer til at arbejde med filer

§ Grundlæggende kommandoer til at arbejde med diske

§ Oprettelse og brug af en batchfil

§ Operativsystem auto-tuning kommandofil AUTOEXEC.BAT

§ Konfiguration af operativsystemet ved hjælp af CONFIG.SYS-konfigurationsfilen

GENERELLE OPLYSNINGER OM HOLD

Algoritme til indlæsning af operativsystem

Operativsystemet er gemt i ekstern hukommelse, normalt på en harddisk, sjældnere på en diskette.

Det er værd at sige, at for normal drift af computeren er det ekstremt vigtigt, at hovedmodulerne i operativsystemet er i RAM. Af denne grund bliver operativsystemet automatisk omskrevet (indlæst) fra disken til RAM, efter at computeren er tændt.

- omskrivning af operativsystemet fra en disk (hard eller floppy) til RAM.

Efter at have tændt for computeren, observeres en ændring i tal på skærmen. Disse tal afspejler processen med at teste RAM med BIOS-programmet. Hvis der opdages en fejl i RAM-cellerne, vises en meddelelse.

Når hardwaretestningen er gennemført, får du adgang til drevet med diskette A, og indikatorlampen ved siden af lyser. Hvis operativsystemet er indlæst fra en diskette, skal du indsætte systemdisketten i drev A før eller under test. Ellers, hvis der ikke er noget operativsystem på disk A, tilgås harddisken, som det fremgår af indikatoren lys ved siden af.

Indlæsning i RAM'en for den 0. sektor på den 0. side af disken, hvor bootloaderen er placeret (BOOT RECORD) begynder. Styringen overføres til bootloaderen, som kontrollerer tilstedeværelsen af IO.SYS-udvidelsesmodulet og MSDOS.SYS-basismodulet på systemdisken. Hvis de er på det sted, der er tildelt dem, indlæses dem i RAM, ellers vil der blive vist en meddelelse om deres fravær. I dette tilfælde anbefales det at downloade igen. Genstartsignalet overfører kontrollen til det permanente BIOS-modul, som igen skriver boot-blokken fra disken ind i RAM osv.

BEMÆRK! Til genstart operativsystemet tryk på tasterne samtidigt i hukommelsen<Сtгl> <АLT> .

Efter vellykket indlæsning af IO.SYS-udvidelsesmodulet og MSDOS.SYS-basismodulet i RAM, indlæses COMMAND.COM-kommandoprocessoren, og CONFIG.SYS-konfigurationsfilen behandles, som indeholder kommandoer til tilslutning af de nødvendige drivere. Denne fil kan mangle, hvis brugeren er tilfreds med den grundlæggende version af operativsystemet.

Derefter behandles kommandofilen AUTOEXEC.BAT. Denne fil bruges til at konfigurere driftsmiljøparametrene. Opret for eksempel en virtuel disk, skift udskrivningstilstande, indlæs hjælpeprogrammer osv.

Bemærk! Filer med filtypenavnet .BAT spiller en særlig rolle, når du arbejder i et systemmiljø. Οʜᴎ indeholder et sæt operativsystemkommandoer eller navne på eksekverbare filer. Efter lancering af en fil med filtypenavnet .BAT, udføres alle kommandoer skrevet i den automatisk efter hinanden.

Hvis filen AUTOEXEC.BAT mangler, bliver du bedt om at indtaste dato og klokkeslæt:

hvis du trykker på enter-tasten, accepteres de såkaldte systemparametre bestemt af computertimeren som den aktuelle dato og klokkeslæt;

Hvis du vil nulstille systemets dato og klokkeslæt, skal du som svar på prompten indtaste værdierne i en af de medfølgende formularer, for eksempel:

25-10-1997 (måned dag år)

7:30:10.00r (timer: minutter: sekunder)

Efter at AUTOEXEC.BAT-filen er færdig med at fungere, og også hvis denne fil ikke er fundet, vil der blive vist en systemdiskprompt på skærmen, f.eks. C:\>. Dette indikerer, at opstartsprocessen er fuldført normalt, og du kan begynde at arbejde ved at indtaste navnet på applikationsprogrammet eller operativsystemkommandoen.

Bemærk. Filerne CONFIG.SYS og AUTOEXEC.BAT mangler muligvis. I dette tilfælde vil driftsmiljøindstillingerne blive sat til standard.

Husk! Det er ekstremt vigtigt at sikre, at operativsystemet er permanent gemt på harddisken. Når du tænder for din computer, skal alle diskettedrev være åbne.

Du skal indsætte disketten med applikationsprogrammer i drevet, efter at overførslen er fuldført.

Testet af programmet

belastning Ingen belastning

på fleksibel hård no

disk disk

Læsning fra floppy disk Læs. med gestus disk

IO.SYS, MSDOS.SYS i boot-sektoren"

belastning Ingen besked

korrekt? "Ingen systemfiler"

Kommando. Com "Ingen systemfiler"

og CONFIG.SYS-filen