Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
1
OS-Design / Re: VertaOS Neuanfang
« am: 20. December 2006, 14:19 »
Das währ auch ne möglichkeit 
22. November 2024, 08:54
Beiträge anzeigen
Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.
Seiten: [1]
2
OS-Design / Re: VertaOS Neuanfang
« am: 20. December 2006, 14:14 »
Taskverwaltung brauch ich für (manche) Treiber und ob ich die gleich im Kernel habe oder später als Kernelmodul lade (ich MUSS ihn ja sehr früh laden) dürfte eigendlich egal sein.
Der Videotreiber im Kernel ist nur für einfache Textausgabe (wenn der Kernel z.B. fehler beim laden des echten Videotreibers hat, kann er was rausschreiben).
Der Videotreiber im Kernel ist nur für einfache Textausgabe (wenn der Kernel z.B. fehler beim laden des echten Videotreibers hat, kann er was rausschreiben).
3
OS-Design / Re: VertaOS Neuanfang
« am: 20. December 2006, 13:31 »
Mir ist wohl bewusst, wenn jemand in den Kernel kommt, dass da quasi alles zu spät ist, aber ich will es eben von vornherein einigermaßen sicher machen.
Aber wie mein Vorredner schon gesagt hat...
Was haltet ihr vom Design?
Ich habe den Text oben angepasst, sodass die änderungen aufgrund der Posts hier oben mit eingeflossen sind.
Danke schonmal ^^
Aber wie mein Vorredner schon gesagt hat...
Was haltet ihr vom Design?
Ich habe den Text oben angepasst, sodass die änderungen aufgrund der Posts hier oben mit eingeflossen sind.
Danke schonmal ^^
4
OS-Design / Re: VertaOS Neuanfang
« am: 20. December 2006, 10:22 »
Danke JensFZ, das war auch mein Gedanke ^^
aber wo bringe ich es am besten unter (userverwaltung)?
und was haltet ihr allgemein vom aufbau (alles)?
aber wo bringe ich es am besten unter (userverwaltung)?
und was haltet ihr allgemein vom aufbau (alles)?
5
OS-Design / Re: VertaOS Neuanfang
« am: 19. December 2006, 22:52 »
Kurz:
Im Kernel:
Speicherverwaltung
Modulverwaltung
Taskmanager
Den Rest als Module / Tasks
FAT12 werde ich vorraussichtlich als aufsatz nehmen (VFS). Damit tu ich mich später leichter beim hinzufügen weiterer Dateisysteme
Wo auch eine Frage währe:
Wo binde ich am besten die Userverwaltung ein? Kernel oder als Modul oder Task.
Nachteil kernel: Ich will so wenig wie möglich drin haben, dass weniger Fehlerquellen drin sind (stabilität)
Nachteil Modul: Leichteres Ziel für Cracker (sicherheit)
Nachteil Task: Siehe Modul
Nachtrag:
Als Verzeichnisstuktur werde ich mich weitgehend an FHS halten, da dieses System mir sehr gut gefällt. (http://www.pathname.com/fhs/pub/fhs-2.3.html)
Im Kernel:
Speicherverwaltung
Modulverwaltung
Taskmanager
Den Rest als Module / Tasks
FAT12 werde ich vorraussichtlich als aufsatz nehmen (VFS). Damit tu ich mich später leichter beim hinzufügen weiterer Dateisysteme
Wo auch eine Frage währe:
Wo binde ich am besten die Userverwaltung ein? Kernel oder als Modul oder Task.
Nachteil kernel: Ich will so wenig wie möglich drin haben, dass weniger Fehlerquellen drin sind (stabilität)
Nachteil Modul: Leichteres Ziel für Cracker (sicherheit)
Nachteil Task: Siehe Modul
Nachtrag:
Als Verzeichnisstuktur werde ich mich weitgehend an FHS halten, da dieses System mir sehr gut gefällt. (http://www.pathname.com/fhs/pub/fhs-2.3.html)
6
OS-Design / VertaOS Neuanfang
« am: 19. December 2006, 16:40 »
Hi,
ich habe vor ca 1-2 jahren mal ein os angefangen VertaOS was ich allerdings aus Zeitgründen einstellen musste. Nun wollte ich wieder anfangen und habe gravierende Fehler im Design festgestellt, so dass es besser währe nochmal neu anzufangen.
Den Aufbau hab ich mir folgend gedacht:
Bootloader FAT12 lädt kernel im RM
Der Kernel switcht in den PM nachdem er die nötigen Treiber geladen hat
Im Kernel enthalten sind folgende Funktionen:
Module (PL0):
Taskmanager
VFS
FDD/HDD
... (kommt später)
Treiber-Tasks (PL2):
Usermanager (Als System, kann nicht beendet werden und wird versteckt
Da der Usermanager als Task läuft, kann er den Kernel nicht direkt beeinflussen und greift nur über eine API auf den Kernel zu.
Normale tasks und Anwendungen laufen auf PL3
Der ganze Rest wird dann Nachgeladen.
Entweder als Modul oder als Task (beides soll möglich sein).
Die Treiber können untereinander Kommunizieren über "Briefkästen", also ein Treiber schickt eine Anfrage/Befehl an einen anderen. Dieser wiederum kann ihn dann annehmen und antworten oder auch ablehnen, muss hier aber eine Nachricht an den Kernel schicken. Sollte der Befehl abgelehnt und keine Nachricht an den Kernel geschickt werden, wird es als Nichtausführung der Aufgabe gewertet und der Treiber wird als defekt angesehen und wieder entladen (unload - weiß kein vergleichbahr deutsches wort).
Das Paging etc will ich etwas abändern, so dass ich eine art "Dateisystem" im Ram habe. Das hat den vorteil, dass wenn ein Fehler auftreten sollte das Debuggen um etliches erleichtert wird (als Zusatzfunktion).
Die Geräte werden wie bei Linux über DevFS angesprochen.
Es wird die möglichkeit geben, dass ein Programm eine Anfrage an den Kernel schickt (ev. mit bestätigung des users), damit die Anwendung dann z.B. direkt auf die Grafikkarte zugreifen kann ohne auf die verhälltnissmäßig langsame API zurückzugreifen.
Für kompatibilität werde ich mich so gut ich kann an den POSIX standard (IEEE Std 1003.1) halten.
Die Ordnerstruktur werde ich an FHS anlehnen (nur anlehnen ^^):
Was haltet ihr davon und habt Ihr Vorschläge, was man besser machen könnte? (es soll aber realisierbahr bleiben ^^)
ich habe vor ca 1-2 jahren mal ein os angefangen VertaOS was ich allerdings aus Zeitgründen einstellen musste. Nun wollte ich wieder anfangen und habe gravierende Fehler im Design festgestellt, so dass es besser währe nochmal neu anzufangen.
Den Aufbau hab ich mir folgend gedacht:
Bootloader FAT12 lädt kernel im RM
Der Kernel switcht in den PM nachdem er die nötigen Treiber geladen hat
Im Kernel enthalten sind folgende Funktionen:
Code: [Auswählen]
Protectedmode (GDT, TSS etc)
Interrupts (IDT, PIC etc)
Memorymanager
Video Treiber (Nur für Kernelmeldungen)Module (PL0):
Taskmanager
VFS
FDD/HDD
... (kommt später)
Treiber-Tasks (PL2):
Usermanager (Als System, kann nicht beendet werden und wird versteckt
Da der Usermanager als Task läuft, kann er den Kernel nicht direkt beeinflussen und greift nur über eine API auf den Kernel zu.
Normale tasks und Anwendungen laufen auf PL3
Der ganze Rest wird dann Nachgeladen.
Entweder als Modul oder als Task (beides soll möglich sein).
Die Treiber können untereinander Kommunizieren über "Briefkästen", also ein Treiber schickt eine Anfrage/Befehl an einen anderen. Dieser wiederum kann ihn dann annehmen und antworten oder auch ablehnen, muss hier aber eine Nachricht an den Kernel schicken. Sollte der Befehl abgelehnt und keine Nachricht an den Kernel geschickt werden, wird es als Nichtausführung der Aufgabe gewertet und der Treiber wird als defekt angesehen und wieder entladen (unload - weiß kein vergleichbahr deutsches wort).
Das Paging etc will ich etwas abändern, so dass ich eine art "Dateisystem" im Ram habe. Das hat den vorteil, dass wenn ein Fehler auftreten sollte das Debuggen um etliches erleichtert wird (als Zusatzfunktion).
Die Geräte werden wie bei Linux über DevFS angesprochen.
Es wird die möglichkeit geben, dass ein Programm eine Anfrage an den Kernel schickt (ev. mit bestätigung des users), damit die Anwendung dann z.B. direkt auf die Grafikkarte zugreifen kann ohne auf die verhälltnissmäßig langsame API zurückzugreifen.
Für kompatibilität werde ich mich so gut ich kann an den POSIX standard (IEEE Std 1003.1) halten.
Die Ordnerstruktur werde ich an FHS anlehnen (nur anlehnen ^^):
Code: [Auswählen]
/ Hauptverzeichnis
/bin Programme (Nur Verzeichnis)
|- /sys Systemprogramme
|- /programm Programme installieren in separate Ordner
/boot Bootloader
/doc Dokumentationen (Nur Verzeichnis)
|- /sys Dokumentationen über das System
|- /programm Dokumentationen über ein Programm
/etc Konfigurationen (Nur Verzeichnis)
|- /sys Systemkonfigurationsdateien
|- /programm Konfigurationen der einzelnen Programme
/home Heimatsverzeichnis (Nur Verzeichnis)
|- /benutzer Heimatsverzeichnis eines Benutzers
|- /root Heimatsverzeichnis des Administrators
/lib Bibliotheken (Nur Verzeichnis)
|- /lib-name Bibliotheken liegen in separaten Ordnern
/sbin Programme für Admin (Nur Verzeichnis)
|- /programm Programme die vom Administrator ausgeführt werden können
/tmp Temporärer Ordner
Was haltet ihr davon und habt Ihr Vorschläge, was man besser machen könnte? (es soll aber realisierbahr bleiben ^^)
7
Lowlevel-Coding / Nach neuinstallation, fehler
« am: 26. July 2005, 01:58 »
hab das ++ jeweils vergessen (außer an der 1. stelle)
<-- Hab den Fehler mehr oder weniger gefunden... gcc 4.0 und es geht...
naja. ich hoffe mal mein windoof bleibt diesmal erhalten, dass ich nicht nochmal so was erlebe
<-- Hab den Fehler mehr oder weniger gefunden... gcc 4.0 und es geht...
naja. ich hoffe mal mein windoof bleibt diesmal erhalten, dass ich nicht nochmal so was erlebe
8
Lowlevel-Coding / Nach neuinstallation, fehler
« am: 24. July 2005, 17:27 »
ok... war ein komischer fehler (wenn es einer war).
hab im kernel16 times weggelassen und schon ging es
aber jetzt kommt ein zweites prob.
Vesa initialisiert (mode 0x118) und die überprüfung ergiebt auch, dass ich 24Bit Farbtiefe habe. Jedoch zeichnet er immer nur in graustufen.
woran kann das liegen?
Zeichnen tu ich mit folgenden befehlen:
VideoMem zeigt auf VbeModePhysBasePtr.
Hab auch schon versucht nicht jede farbe einzeln reinzuladen sondern alle zusammen aber auch ohne erfolg...
hab im kernel16 times weggelassen und schon ging es
aber jetzt kommt ein zweites prob.
Vesa initialisiert (mode 0x118) und die überprüfung ergiebt auch, dass ich 24Bit Farbtiefe habe. Jedoch zeichnet er immer nur in graustufen.
woran kann das liegen?
Zeichnen tu ich mit folgenden befehlen:
Code: [Auswählen]
pos = ((y*swidth)+x)*(bpp/8);
VideoMem[pos] = B;
VideoMem[pos] = G;
VideoMem[pos] = R;VideoMem zeigt auf VbeModePhysBasePtr.
Hab auch schon versucht nicht jede farbe einzeln reinzuladen sondern alle zusammen aber auch ohne erfolg...
9
Lowlevel-Coding / Nach neuinstallation, fehler
« am: 19. July 2005, 15:08 »
es geht ja auch mit den 3.x nicht...
beim 4 hängt sich der pc auf und bei 3 startet er neu
beim 4 hängt sich der pc auf und bei 3 startet er neu
10
Lowlevel-Coding / Nach neuinstallation, fehler
« am: 18. July 2005, 21:35 »
leider weiß ich nicht mehr, welche versionen ich hatte...
gcc habe ich von http://www.delorie.com/djgpp/
Komisch ist nur, warum startet der pc nach einer weile neu?
ich hab zwar vehlerhafte addressierung im hinterkopf, aber dann würde es nicht so lange dauern (so 10-20 sec)
-> acho so... ja ich habe alles runtergeladen
gcc habe ich von http://www.delorie.com/djgpp/
Komisch ist nur, warum startet der pc nach einer weile neu?
ich hab zwar vehlerhafte addressierung im hinterkopf, aber dann würde es nicht so lange dauern (so 10-20 sec)
-> acho so... ja ich habe alles runtergeladen
11
Lowlevel-Coding / Nach neuinstallation, fehler
« am: 17. July 2005, 20:39 »
Hi,
ich musste mein windoof neu installieren, was eigendlich kein problem ist. allerdings wollte ich danach mein os neu kompillieren (auch wider mit djgpp, allerdings wusste ich nicht mehr welche version ich davor hatte).
also probierte ich es mit gcc 4.0, was nicht ging.
also 3.6 versucht, da startet er nach einer weile neu und bei 3.4 auch.
Das prob kommt an folgender stelle:
Bootloader lädt Kernel soweit so gut
Vesa wird geladen, auch das geht noch.
Bildschirm mit der farbe füllen, geht nicht und wenn er dann einen pixel zeichnen will neustart.
allerdings verwende ich den gleichen code wie davor und da hat alles funktioniert!?!
ich musste mein windoof neu installieren, was eigendlich kein problem ist. allerdings wollte ich danach mein os neu kompillieren (auch wider mit djgpp, allerdings wusste ich nicht mehr welche version ich davor hatte).
also probierte ich es mit gcc 4.0, was nicht ging.
also 3.6 versucht, da startet er nach einer weile neu und bei 3.4 auch.
Das prob kommt an folgender stelle:
Bootloader lädt Kernel soweit so gut
Vesa wird geladen, auch das geht noch.
Bildschirm mit der farbe füllen, geht nicht und wenn er dann einen pixel zeichnen will neustart.
allerdings verwende ich den gleichen code wie davor und da hat alles funktioniert!?!
12
Offtopic / Dinge die euch so passiert sind (Computer)
« am: 07. July 2005, 17:15 »
Ich wollte mal wissen, ob es manchen von euch so ergeht wie mir heute:
Ich ruf in einem PC-Laden für gebrauchte Hardware an und fragte: "Haben Sie 19'' Gehäuse?"
Verkäufer: "Ja natürlich."
Ich: "Was kosten die?"
Verkäufer: "20⬠für die kleinen und 50 für die großen"
Ich: "Kann ich heute noch vorbeikommen?" (war ja schon 17 Uhr)
Verkäufer: "Ja. Wir haben bis 18:30 offen"
Also fuhr ich hin und wollte mir ein 19" Gehäuse mit 4 HE kaufen.
Angekommen, sagte ich, dass ich vorhin zwecks dem 19" Gehäuse angerufen habe und es kaufen wolle.
Und was brachte mir der Verkäufer? EIN BIGTOWER
Nachdem ich Ihm erklähr habe, was denn ein 19" Gehäuse sei, brachte er auch eines. Sagte er könne es allerdings nur mit "Inhalt" Verkaufen.
Es war eine 20GB Platte, 64MB Ram und ein P2 mit 350 Mhz drinne.
Verkäufer: "Für 300⬠können Sie es mitnehmen".
WIE BITTE???
Ich ruf in einem PC-Laden für gebrauchte Hardware an und fragte: "Haben Sie 19'' Gehäuse?"
Verkäufer: "Ja natürlich."
Ich: "Was kosten die?"
Verkäufer: "20⬠für die kleinen und 50 für die großen"
Ich: "Kann ich heute noch vorbeikommen?" (war ja schon 17 Uhr)
Verkäufer: "Ja. Wir haben bis 18:30 offen"
Also fuhr ich hin und wollte mir ein 19" Gehäuse mit 4 HE kaufen.
Angekommen, sagte ich, dass ich vorhin zwecks dem 19" Gehäuse angerufen habe und es kaufen wolle.
Und was brachte mir der Verkäufer? EIN BIGTOWER
Nachdem ich Ihm erklähr habe, was denn ein 19" Gehäuse sei, brachte er auch eines. Sagte er könne es allerdings nur mit "Inhalt" Verkaufen.
Es war eine 20GB Platte, 64MB Ram und ein P2 mit 350 Mhz drinne.
Verkäufer: "Für 300⬠können Sie es mitnehmen".
WIE BITTE?
??
14
Lowlevel-Coding / Wieder mal Vesa...
« am: 04. July 2005, 15:34 »
Danke. Es lag wirklich am A20 gate.
15
Lowlevel-Coding / Wieder mal Vesa...
« am: 03. July 2005, 14:38 »
danke.. hab es jetzt mal auf nem normalen pc getestet und da füllt er den halben bildschirm mit der farbe.
Jedoch macht er nicht den ganzen bildschirm...
Wie kann ich bochs mitteilen, dass er 32 bit verwenden soll? hab nix mit google gefunden.
<->
Hab jetzt mal Verschiedene Modis probiert...
er zeichnet bei 640x480 fast alles, bei 800x600 nur noch die hälfte und bei 1024x768 ca. 1/3.
Kann es sein, dass ich vesa mit lfb nicht richtig initialisiert hab?
Jedoch macht er nicht den ganzen bildschirm...
Wie kann ich bochs mitteilen, dass er 32 bit verwenden soll? hab nix mit google gefunden.
<->
Hab jetzt mal Verschiedene Modis probiert...
er zeichnet bei 640x480 fast alles, bei 800x600 nur noch die hälfte und bei 1024x768 ca. 1/3.
Kann es sein, dass ich vesa mit lfb nicht richtig initialisiert hab?
16
Lowlevel-Coding / Wieder mal Vesa...
« am: 03. July 2005, 13:50 »
so... hab es jetzt geschafft, das er pixel zeichnen kann.
Allerdings nicht so wie er soll.
Wenn ich ein Pixel zeichnen will, stimmen die koordinaten nicht und beim bildschirm füllen ist der ganze bildschirm "gestrichelt"
Der Code ist der gleiche geblieben (hab nur die header etwas abgeändert, wo auch der fehler war)
Allerdings nicht so wie er soll.
Wenn ich ein Pixel zeichnen will, stimmen die koordinaten nicht und beim bildschirm füllen ist der ganze bildschirm "gestrichelt"
Der Code ist der gleiche geblieben (hab nur die header etwas abgeändert, wo auch der fehler war)
17
Lowlevel-Coding / Wieder mal Vesa...
« am: 02. July 2005, 20:11 »
Hi, ich sitze inzwischen seit über 1 woche daran, mit vesa was zu zeichnen.
Vesa initialisiere ich ohne probleme im kernel16.asm mit folgenden code:
danach wird in den PMode geschalten. der Vesamodeinfoblock müsste sich jetzt an 0x8000 befinden (im pmode).
hier ist meine vesa.c:
Das Problem sieht folgend aus:
Er schaltet den Vesamodus, initialisiert den PMode, aber ich kann weder einen pixel zeichnen, noch den bildschirm füllen...
Danke schon mal
Vesa initialisiere ich ohne probleme im kernel16.asm mit folgenden code:
Code: [Auswählen]
SetVesaMode:
push ax
push bx
mov ax, 4f00h
mov bx, 0x7e0
mov es, bx
mov di, 0x0
int 0x10
cmp ax, 0x004f
jne .1
mov bx, 0x7e0
mov es, bx
mov di, 0x0
mov ax, [es:di+4]
mov ax, 0x4f01
mov di, 0x0
mov bx, 0x800 ; VbeInfoBlock nach 0x8000
mov es, bx
mov cx, 0x0115 ; Videomodus 800x600 mit lfb
int 0x10
mov ax, 0x4f02
mov bx, 0x4115
int 0x10
cmp ax, 0x004f
je .3
.1:
mov si, msg_VesaError
call PrintString
.2:
jmp .2
.3:
pop bx
pop ax
retdanach wird in den PMode geschalten. der Vesamodeinfoblock müsste sich jetzt an 0x8000 befinden (im pmode).
hier ist meine vesa.c:
Code: [Auswählen]
unsigned long *Video;
unsigned short sWidth, sHeight;
unsigned short VBEModeInfo = 0x8000;
void InitVideo()
{
unsigned long *pLong = (unsigned long *)(VBEModeInfo + 0x28);
unsigned short *pShort = (unsigned short*)(VBEModeInfo + 0x12);
Video = (unsigned long*)(pLong[0]);
sWidth = pShort[0];
sHeight = pShort[1];
}
void FillScreen(unsigned long color)
{
unsigned long End = sWidth * sHeight, i;
for (i=0;i<End;i++)
Video[i] = color;
}
void PutPixel(short x, short y, unsigned long color)
{
if (x>=0 && y>=0 && x<sWidth && y<sHeight)
Video[y*sWidth+x] = color;
}
...Das Problem sieht folgend aus:
Er schaltet den Vesamodus, initialisiert den PMode, aber ich kann weder einen pixel zeichnen, noch den bildschirm füllen...
Danke schon mal
Seiten: [1]