Nytt OS : Dvorient diskusjon

[Emancipate]

> Det skal være et fullverdig OS

Jo, men skal kernelen være en microkernel eller ikke?

[GeirGrusom]

Det skal være en microkernel ja

Edit: jeg har skrevet biblioteket for behandling av DMA nå.

Over til harddisken behandling

Endret 31. mars 2007 av GeirGrusom

[Hayer]

Oki, å når kan jeg/vi for vente at dette OS er klar for beta testing?

[GeirGrusom]

Vi er i en "low" fase nå, siden jeg er eneste som har noe særlig greie på hardware relatert programmering (low level)

DMA controlleren er i orden, minne behandling er nesten ferdig, og skal begynne med lasting av programmer.

Når dette er ferdig, kan hvem som helst kaste seg på.

 

Edit: legger til at jeg jobber med et prosjekt jeg får betalt for, og må prioritere dett, men ser på dvorient som et viktig prosjekt.

Grunnen til at jeg egentlig fikk mest lyst til å drive med dette, er at veldig mye datamaskingreier er veldig gammelt.

Dette forstår du spesielt hvis du går lett igjennom instruksjonssettet til x86, siden en moderne prosessor fortsatt støtter programmer skrevet i '79 (selvom OS-et ikke støtter det)

:S

Endret 14. april 2007 av GeirGrusom

[Hayer]

"kan hvem som helt kaste seg på."

 

I hvilket språk? Alle?

[Giddion]

Har dere planer om å lage en version med x64 instruksjonssettet også?

[Dead_Rabbit]

@Hayer

En god del språk er jo skrevet i C, så når vi først får portet C-biblioteket så kan jo andre språk som f.eks. Python kompileres og tas i bruk.

 

@ Giddeon:

Det var vel planen i utgangspunktet, men jeg tror vi kommer til å konsentrere oss om x86 først. Få på plass alle grunn-komponentene og sånt før vi begynner med x64.

[Emancipate]

Har dere prosesser enda? Hvis ja er jeg nyskjerrig på hvordan dere sjekker om fpuregisterene må bevares for en prosess (eller om dere bare lagrer dem uansett).

 

Edit: er det rebuilt.bat man skal bruke for å kompilere prosjektet?

Endret 16. april 2007 av tsg1zzn

[GeirGrusom]

Ja

Rebuild.bat tar rett og slett og kopierer alt fra build.sh, jeg husker ikke helt hvilken som gjør hva, men foreløpig funker det kun å linke med nasm kode i linux (vet ikke om det er en nasm bug eller linker bug :-P du får en "invalid file format melding fra linkeren i Windows)

 

Vi har ikke kommet så veldig langt enda, men det er minnebehandling som har blitt det største hinderet (grunnen til at Jaffe feiget ut)

Hvis noen vet masse om Protected mode og virtual addressing så må dere gjerne fortelle

Hvordan får vi kjørt kode og delt ressursert på tvers av prosesser? det er et mysterium....som vi ikke har løst enda...

[Jaffe]

Ja

Rebuild.bat tar rett og slett og kopierer alt fra build.sh, jeg husker ikke helt hvilken som gjør hva, men foreløpig funker det kun å linke med nasm kode i linux (vet ikke om det er en nasm bug eller linker bug :-P du får en "invalid file format melding fra linkeren i Windows)

 

Vi har ikke kommet så veldig langt enda, men det er minnebehandling som har blitt det største hinderet (grunnen til at Jaffe feiget ut)

Hvis noen vet masse om Protected mode og virtual addressing så må dere gjerne fortelle

Hvordan får vi kjørt kode og delt ressursert på tvers av prosesser? det er et mysterium....som vi ikke har løst enda...

8398315[/snapback]

 

Jeg tror prosessbehandling vil bli et like stort hinder som minnebehandling, f.eks. på grunn av det tsg1zzn sier (switching av FPU-registre). Når det gjelder minnebehandling har ikke protected mode og virtuelle adresser noe med det å gjøre direkte, men det er hvordan man skal gi en prosess et allokert minneområde. Jeg vil foreslå at kernel allokerer et fysisk område og "plugger" det inn i det virtuelle adresseområdet (page directory etc.) til prosessen og returnerer adressen til området i page directory området ble satt inn.

[Emancipate]

Hvordan får vi kjørt kode og delt ressursert på tvers av prosesser? det er et mysterium....som vi ikke har løst enda...

Hehe, det må være noe magisk som må til. :!:

 

I et protected mode OS vil du jo helst ikke at kode skal kjøres på tvers av prosesser. Hvis det går an uten videre er det en GIGA-sikkerhetssvikt.

 

I windows f.eks. kan jo ikke mitt program bare uten videre stappe inn kode i ditt program (mens det kjører).

 

Dette skaper selvfølgelig noen "små" problemer med deling av ressurser og sånt, men det er det sikkert lurest å ikke tenke for mye på...

 

Det med protected mode er veldig enkelt i prinsippet, men jeg vet ikke helt om det er noen store problemer med det i praksis. Uansett så er nå teorien sånn:

 

Det er en diger tabell som holder styr på hvilke addresser i minneområdet til en prosess som hører til hvilket fysiske minneområde. (Som Jaffe sa - tror jeg.) Ganske enkelt å forstå.

 

Hvis du vil dele funksjoner mellom programmer er det vanlig med dll-filer (eller .so-filer på linux). Prinsippet bak disse er også ganske enkelt. Hele skiten (dll-fil med kode og data og alt som hører med) lastes ganske enkelt inn i det virtuelle minneområdet til prosessen og så er den klar til bruk. Men hvis alle prosesser som bruker f.eks. user32.dll skulle hatt sin egen kopi ville det blitt sinnsykt for tomt for minne. Derfor har Windows et triks som er som følgende: Kun én kopi av KODEN som tilhører dll-fila er lastet inn i fysisk minne. Men alle prosessene merker ikke noe til dette. Grunnen er at tabellen som holder styr på hvilket virtuelt minne som peker til hvilket fysisk minne peker til det samme fysiske minneområde for alle prosessene som bruker fila. Figur:

 

Opera.exe

virtuelt minne, fysisk minne

10, 94659

100, 15024

...

user32.dll er lastet inn her:

400000, 999999

 

Explorer.exe

virtuelt minne, fysisk minne

10, 63485

100, 571542

...

user32.dll er lastet inn her:

480000, 999999

 

Altså at flere virtuelle minne-områder peker til samme fysiske minneområde. Sånn kan man dele på kode. Det som er essensielt er at ikke dette minnet kan SKRIVES til fra prosessen, kun kjøres.

 

Hvorfor skrev jeg dette?

Endret 16. april 2007 av tsg1zzn

[Jaffe]

Det du sier er helt riktig, men det er dog bare paging du beskriver, ikke selve protected mode (men protected mode er ikke viktig å bry seg om etter at viktige deler som GDT og IDT er lastet inn (og dermed segmenter er definert). Men det du skrev underbygger hvertfall min oppfatning av dette med å sette samme fysiske område inn i forskjellige prosessers virtuelle område for å dele ressursen, så da har jeg et mye bedre bilde av det hele )

[Dead_Rabbit]

Nå kan jeg veldig lite om dette her, men jeg stussa på hvordan man da gjør det med funkjsons-argumenter. Etter hva jeg forstår ligger disse ofte «foran» selve koden på stacken. Må man ikke da være i stand til å skrive til dette området i såfall?

 

Mulig jeg bare misforstår totalt her altså.. :s

[Gjakmarrja]

Man pusher vel argumentene før funksjonen kalles ja.

[Jaffe]

Nå kan jeg veldig lite om dette her, men jeg stussa på hvordan man da gjør det med funkjsons-argumenter. Etter hva jeg forstår ligger disse ofte «foran» selve koden på stacken. Må man ikke da være i stand til å skrive til dette området i såfall?

 

Mulig jeg bare misforstår totalt her altså.. :s

8402050[/snapback]

 

Det ligger aldri kode på stacken, men det kan ligge pekere til kode.

 

Nå er jeg ikke helt sikker på hvordan man gjør dette med stack o.l., men kernelen har i alle fall alltid mulighet for å lese i adresseområdet til prosessen (og dermed stacken). Dette kan du sikkert lese mer om på http://osdever.net eller noe.

[Emancipate]

Nå kan jeg veldig lite om dette her, men jeg stussa på hvordan man da gjør det med funkjsons-argumenter. Etter hva jeg forstår ligger disse ofte «foran» selve koden på stacken. Må man ikke da være i stand til å skrive til dette området i såfall?

8402050[/snapback]

Hvor man plasserer parametrene velger man egentlig selv, men kallet og funksjonen må være enige om hvordan det skal gjøres. Det vanlig er å pushe parametrene på stakken, ja.

 

Hvis funksjonen er i en dll er det ikke noe problem, dll-fila kjører i samme minne-område som programmet, og er "blitt en del av" programmet i minnet.

 

Så til løsningen på "mysteriet":

Hvis funksjonen er i kernelen (et systemkall) kan man bruke et interrupt. Linux bruker interrupt 80h og legger nummeret på funksjonen som skal kalles opp i eax. Når programmet kjører interrupt 80h overføres kontrollen til kernelens interrupt-handler.

[Jaffe]

Nå kan jeg veldig lite om dette her, men jeg stussa på hvordan man da gjør det med funkjsons-argumenter. Etter hva jeg forstår ligger disse ofte «foran» selve koden på stacken. Må man ikke da være i stand til å skrive til dette området i såfall?

8402050[/snapback]

Så til løsningen på "mysteriet":

Hvis funksjonen er i kernelen (et systemkall) kan man bruke et interrupt. Linux bruker interrupt 80h og legger nummeret på funksjonen som skal kalles opp i eax. Når programmet kjører interrupt 80h overføres kontrollen til kernelens interrupt-handler.

8405116[/snapback]

 

Dette er ingen løsning på mysteriet. Det er ikke hvordan selve funksjonskallet skjer, det er hvordan argumenter blir gitt til kernelen.

[Emancipate]

Å, det er ikke noe problem. Kernelen har tilgang til alt den vil ha tilgang til, så det er bare å bestemme seg for noe. F. eks. kan et lite minneområde i hver prosess være reservert for parametere, eller man kan bruke kun registere, eller man kan bruke stakken.

 

Edit: Linux bruker registere: ebx, ecx, edx, esi, edi, ebp

Endret 17. april 2007 av tsg1zzn

[Hayer]

en tink som sikkrt er LANGT fram i tiden, men har dere tenkt å bygge med støtte for DirectX?

[GeirGrusom]

Nei.

Dersom dette ikke kan kjøres gjennom Wine, vil det nok heller aldri kjøre i dvorient.

Dette avhenger en del av driverstøtte, samt at å lage DirectX til et annet OS er et eget prosjekt i seg selv.