Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
501
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 12. December 2008, 20:38 »
Bin mir grad nicht sicher.
Das muss doch heißen:
MULTIBOOT_FLAGS equ 0x02
oder?
Das muss doch heißen:
MULTIBOOT_FLAGS equ 0x02
oder?
27. April 2024, 17:16
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.
502
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 12. December 2008, 20:01 »
Mein Vertrauen in den Code ist nicht unerschütterlich.
Ich wollte nur erst mal den "schlimmeren" Fehler beheben.
Habe nun auch das Problem entdeckt.
Der interpretiert eine binäre 0 als "n".
Noch weiß ich nicht wieso.
Habe mir mal eine Methode geschrieben, die mir ints als bin ausgibt und dabei habe ich gesehen, dass mi_flags auf 0 steht.
Leider weiß ich nicht wieso.
Er soll erst einmal die Größe für die bitmap ermitteln.
Das klappt nicht, da das Flag nicht gesetzt ist.
Ich wollte nur erst mal den "schlimmeren" Fehler beheben.
Habe nun auch das Problem entdeckt.
Der interpretiert eine binäre 0 als "n".
Noch weiß ich nicht wieso.
Habe mir mal eine Methode geschrieben, die mir ints als bin ausgibt und dabei habe ich gesehen, dass mi_flags auf 0 steht.
Leider weiß ich nicht wieso.
Er soll erst einmal die Größe für die bitmap ermitteln.
Das klappt nicht, da das Flag nicht gesetzt ist.
503
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 12. December 2008, 19:27 »
Naja,
ich habe mir einfach eine Methode geschrieben, die einen int Ziffernweise bearbeitet und dann den int + '0' rechnet, damit ich auf ASCII-Int komme.
Das dann auf (char) umgewandelt und ausgegeben.
Wo soll da was nicht stimmen?
Aber das löst ja nicht mein Hauptproblem mit dem Multiboot.
Gruß
rizor
ich habe mir einfach eine Methode geschrieben, die einen int Ziffernweise bearbeitet und dann den int + '0' rechnet, damit ich auf ASCII-Int komme.
Das dann auf (char) umgewandelt und ausgegeben.
Wo soll da was nicht stimmen?
Aber das löst ja nicht mein Hauptproblem mit dem Multiboot.
Gruß
rizor
504
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 12. December 2008, 17:50 »
Darüber habe ich mich ja auch gewundert.
Meine Methode zur Bestimmung der Zahlen stimmt aber.
Das habe ich getestet.
Meine Methode zur Bestimmung der Zahlen stimmt aber.
Das habe ich getestet.
505
Lowlevel-Coding / Multibootstruktur funktioniert nicht
« am: 12. December 2008, 17:40 »
Nabend zusammen,
ich bin eben mit meinem Physikalischen Speichermanager fertig geworden.
Leider funktioniert die Multibootstruktur die ich aus dem LOST-Projekt übernommen habe nicht.
Er kann die Speichergröße nicht bestimmen.
Ich habe mir mal die Werte der mb_info->mi_flags ausgegeben.
Da erhalte ich als Dezimalwert "n".
Beim verunden kommt dann auch "n" heraus. Wenn ich es mit der Konstanten HAS_MMAP verunde.
Woran liegt das?
Kann es sein, dass GRUB nicht richtig funktioniert?
Gruß
rizor
ich bin eben mit meinem Physikalischen Speichermanager fertig geworden.
Leider funktioniert die Multibootstruktur die ich aus dem LOST-Projekt übernommen habe nicht.
Er kann die Speichergröße nicht bestimmen.
Ich habe mir mal die Werte der mb_info->mi_flags ausgegeben.
Da erhalte ich als Dezimalwert "n".
Beim verunden kommt dann auch "n" heraus. Wenn ich es mit der Konstanten HAS_MMAP verunde.
Woran liegt das?
Kann es sein, dass GRUB nicht richtig funktioniert?
Gruß
rizor
506
Lowlevel-Coding / Re: Inline ASM in g++
« am: 12. December 2008, 08:17 »
Hi,
ich bin mir nicht sicher, aber ich glaub es müsste so aussehen:
ich bin mir nicht sicher, aber ich glaub es müsste so aussehen:
Code: [Auswählen]
asm ("mov $0x80000002,%eax;"
"cpuid;"
"mov %eax":"m"(cpuidstring));
507
Lowlevel-Coding / Re: LowLevel-Coding mit Code::Blocks
« am: 11. December 2008, 16:53 »
Habe nun leider ein neues Problem mit dem Makefile.
Beim Kompilieren wird mir gesagt, dass er die COBJ-Files nicht findet. Was ja auch richtig ist.
Woran liegt das?
Beim Kompilieren wird mir gesagt, dass er die COBJ-Files nicht findet. Was ja auch richtig ist.
Woran liegt das?
508
Lowlevel-Coding / Re: LowLevel-Coding mit Code::Blocks
« am: 10. December 2008, 23:19 »
Beim Compiler habe ich -nostdinc angegeben.
Ich habe in der Zwischenzeit veruscht mir ein eigenes Makefile zu bauen.
Leider bekomme ich da den Fehler:
Woran liegt das?
Habe leider noch nicht viel Erfahrungen mit makefiles.
Mein Makefile sieht so aus:
Danke.
Gruß
rizor
Ich habe in der Zwischenzeit veruscht mir ein eigenes Makefile zu bauen.
Leider bekomme ich da den Fehler:
Code: [Auswählen]
Makefile:19: *** missing separator. Schluss.Woran liegt das?
Habe leider noch nicht viel Erfahrungen mit makefiles.
Mein Makefile sieht so aus:
Code: [Auswählen]
# the compiler-paths and the flags for the compiler
CC = /usr/bin/gcc
CFLAGS = -Wall -O3 -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -march=i386 -I./kernel/include -c
ASM = /usr/bin/nasm
ASMFLAGS = -felf
# the path to the linker and his flags
LD = /usr/bin/ld
LDFLAGS = -T linker.ld
#the paths to the source files
CSRC = boot_kernel.c boot_system.c kernel/gdt.c kernel/kernel32.c kernel/display/display.c kernel/interrupt/exception.c kernel/interrupt/idt.c kernel/interrupt/irq.c kernel/interrupt/pic.c kernel/interrupt/pit.c kernel/memory/physmem.c
ASMSRC = boot_system.asm kernel/interrupt/exception.asm kernel/interrupt/irq.asm
#the paths to the object files
COBJ = obj/boot_kernel.c.o obj/boot_system.c.o obj/gdt.c.o obj/kernel32.c.o obj/display.c.o obj/exception.c.o obj/idt.c.o obj/irq.c.o obj/pic.c.o obj/pit.c.o obj/physmem.c.o
ASMOBJ = obj/boot_system.asm.o obj/exception.asm.o obj/irq.asm.o
compileASM: $(ASMOBJ) $(COBJ)
$(ASM) $(ASMFLAGS) -o $(ASMOBJ) $(ASMSRC)
$(CC) $(CFLAGS) -o $(COBJ) $(CSRC)
$(LD) $(LDFLAGS) -o bin/kernel.bin $(COBJ) $(ASMOBJ)
Danke.
Gruß
rizor
509
Lowlevel-Coding / LowLevel-Coding mit Code::Blocks
« am: 10. December 2008, 21:40 »
Nabend zusammen,
benutzt einer von euch auch die o.g. IDE?
Mein Problem ist, dass der Linker meckert, dass er __init_array_end nicht findet.
Wenn ich die object-files von Hand linke, dann geht es.
Dann habe ich nur das Problem, dass der Qemu sagt, dass es sich bei dem Programm nicht um eine executable handelt.
Woran liegt das?
Kann es sein, dass ich den Compiler falsch eingestellt habe in der IDE?
Wenn ja, was und wie muss ich denn alles einstellen?
Danke.
Gruß
rizor
benutzt einer von euch auch die o.g. IDE?
Mein Problem ist, dass der Linker meckert, dass er __init_array_end nicht findet.
Wenn ich die object-files von Hand linke, dann geht es.
Dann habe ich nur das Problem, dass der Qemu sagt, dass es sich bei dem Programm nicht um eine executable handelt.
Woran liegt das?
Kann es sein, dass ich den Compiler falsch eingestellt habe in der IDE?
Wenn ja, was und wie muss ich denn alles einstellen?
Danke.
Gruß
rizor
510
Lowlevel-Coding / Re: Bitmaps
« am: 10. December 2008, 15:35 »
Bei meinem Compiler-Fehler konnte ich den Schädling nun finden.
Das problem liegt bei BITS_PER_ELEMENT (8*sizeof(unsigned int))
Leider bekomme ich den Fehler nur behoben, wenn ich die Berechnung der Größe direkt angebe, dann kompiliert er.
Aber wieso kompiliert er es nicht mit BITS_PER_ELEMENT?
Wenn ich es auslagere und dann die neue Variable angebe, meldet er, dass BITS_PER_ELEMENT ohne Auswirkungen bleibt.
Das problem liegt bei BITS_PER_ELEMENT (8*sizeof(unsigned int))
Leider bekomme ich den Fehler nur behoben, wenn ich die Berechnung der Größe direkt angebe, dann kompiliert er.
Aber wieso kompiliert er es nicht mit BITS_PER_ELEMENT?
Wenn ich es auslagere und dann die neue Variable angebe, meldet er, dass BITS_PER_ELEMENT ohne Auswirkungen bleibt.
511
Lowlevel-Coding / Re: Bitmaps
« am: 08. December 2008, 13:34 »Mein Problem ist nur, dass ich nicht weiß, wo mein Kernel liegt.Den Anfang kennst du, weil du den ja sowieso dem Linker vorgibst. Aber wie willst du rauskriegen, wo der Kernel zu Ende ist?
Ich habe gesehen, dass ihr das im linker macht.
Ich habe leider nur keine Ahnung von linker-files.
Nun habe ich mir überlegt, dass ich das doch auch von Hand berechnen kann.
Das müsste doch ohne weiteres gehen, oder?
Ich habe mir mal den Linker vom LOST angeschaut.
Da berechnest du doch nur ALGN(4096) von der Startadresse und das ist das Ende.
Zu dem Code-Stück:
Da ist sonst kein Fehler.
Code: [Auswählen]
void phys_mark_range_free(physaddr_t block , size_t size){
size_t i;
for(i = 0; i < size; i++){
size_t bitmap_index = (size_t) block / BLOCK_SIZE / BITS_PER_BLOCK;
physmemm_bitmap[bitmap_index] |=
1 << (((size_t) block / BLOCK_SIZE) & (BITS_PER_BLOCK - 1));
}
}
Außerdem hat er ein prblem wenn ich mit den werten arbeite, die im Linker definiert sind.
Dann gibt mir der Compiler den Fehler, dass die void* nicht ignoriert werden, wie es sein sollte.
512
Lowlevel-Coding / Re: Bitmaps
« am: 08. December 2008, 01:12 »
Ich habe noch einmal eine Frage zu den Bitmaps.
Damit ich den Speicher mappen kann, muss ich mir ja den reservierten Speicher suchen.
Nun habe ich mir das mal in LOST angeschaut und fand die Idee nicht schlecht, dass ihr gleich mal die Rückgabewerte "parametrisiert".
Mein Problem ist nur, dass ich nicht weiß, wo mein Kernel liegt.
Ich habe gesehen, dass ihr das im linker macht.
Ich habe leider nur keine Ahnung von linker-files.
Nun habe ich mir überlegt, dass ich das doch auch von Hand berechnen kann.
Das müsste doch ohne weiteres gehen, oder?
Dazu habe ich noch eine Frage zu meinem Code:
Hier sagt mein Compiler, dass ihm eine ) fehlt.
Das stimmt ja leider nicht.
Meine IDE meckert auch nicht.
Wieso könnte der gcc meckern?
Vllt ist auch einfach nur zu spät und ich bin betriebsblind.
Gruß
Sven
Damit ich den Speicher mappen kann, muss ich mir ja den reservierten Speicher suchen.
Nun habe ich mir das mal in LOST angeschaut und fand die Idee nicht schlecht, dass ihr gleich mal die Rückgabewerte "parametrisiert".
Mein Problem ist nur, dass ich nicht weiß, wo mein Kernel liegt.
Ich habe gesehen, dass ihr das im linker macht.
Ich habe leider nur keine Ahnung von linker-files.
Nun habe ich mir überlegt, dass ich das doch auch von Hand berechnen kann.
Das müsste doch ohne weiteres gehen, oder?
Dazu habe ich noch eine Frage zu meinem Code:
Code: [Auswählen]
physmemm_bitmap[bitmap_index] |= 1 << (((size_t) block / BLOCK_SIZE) & (BITS_PER_BLOCK - 1));Hier sagt mein Compiler, dass ihm eine ) fehlt.
Das stimmt ja leider nicht.
Meine IDE meckert auch nicht.
Wieso könnte der gcc meckern?
Vllt ist auch einfach nur zu spät und ich bin betriebsblind.
Gruß
Sven
513
Lowlevel-Coding / Re: Bitmaps
« am: 07. December 2008, 01:14 »
Danke.
Hat funktioniert.
Ich habe mir mal den Code des LOST angeschaut.
Dabei kamen ein paar Fragen auf:
1. Wieso nimmt man in die Bitmap nur freien Speicher auf?
Wir suchen uns doch eine obere Grenze, die auf das letzte besetzte Element zeigt.
2. Wieso suchen wir den Speicher erst nach freien Blöcken ab und danach wieder nach besetzten?
Reicht es nicht alles als besetzt zu markieren und danach wieder die wirklich freien Bereiche wieder freigeben?
Gruß
rizor
Hat funktioniert.
Ich habe mir mal den Code des LOST angeschaut.
Dabei kamen ein paar Fragen auf:
1. Wieso nimmt man in die Bitmap nur freien Speicher auf?
Wir suchen uns doch eine obere Grenze, die auf das letzte besetzte Element zeigt.
2. Wieso suchen wir den Speicher erst nach freien Blöcken ab und danach wieder nach besetzten?
Reicht es nicht alles als besetzt zu markieren und danach wieder die wirklich freien Bereiche wieder freigeben?
Gruß
rizor
514
Lowlevel-Coding / Re: Bitmaps
« am: 06. December 2008, 23:46 »ZitatAchso, wo bekomme ich den Multiboot her?Ein Pointer auf die Struktur liegt in ebx (oder war es eax?), wenn er in deinen Kernel springt. Am besten pushst du den auf den Stack, damit du ihn in deiner C-Hauptfunktion als Parameter nehmen kannst.
Ich weiß, den erstellt GRUB aber wo liegt der?
Also muss ich in meiner ASM-Routine kurz vor dem call main ein push ebx machen, oder?
und wenn ich dann main(struct multiboot_info *bla) aufrufe, habe ich die Struktur?
Kenn leider die Konvention bei x86 Prozessoren bei der Parameterübergabe nicht.
Habe vorher nur auf dem ARM Hardwarenah programmiert.
Gruß
rizor
515
Lowlevel-Coding / Re: Bitmaps
« am: 05. December 2008, 22:54 »
Danke für eure Antworten.
Habe jetzt noch eine Frage:
Mein Boot-Loader erstellt ja eine memorymap, anhand derer ich meine erstelle.
Wenn ich mir nun überlege, dass ich meine Blöcke frei wählen kann klingeln bei mir ein paar Alarmglocken.
Sagen wir ich mappe mit 2MB und der GRUB mappt mit 4kB, wenn ich nun versuche zu mappen gibt es doch einen Konflikt, denn unsere Relationen stimmen doch gar nicht überein, oder?
Habe jetzt noch eine Frage:
Mein Boot-Loader erstellt ja eine memorymap, anhand derer ich meine erstelle.
Wenn ich mir nun überlege, dass ich meine Blöcke frei wählen kann klingeln bei mir ein paar Alarmglocken.
Sagen wir ich mappe mit 2MB und der GRUB mappt mit 4kB, wenn ich nun versuche zu mappen gibt es doch einen Konflikt, denn unsere Relationen stimmen doch gar nicht überein, oder?
516
Lowlevel-Coding / Re: Bitmaps
« am: 05. December 2008, 13:33 »
Danke erst mal.
Mal sehen, ob ich es verstanden habe.
Wenn ich mein System starte, packt GRUB meinen Kernel ja an eine Stelle, die ich festgelegt habe.
Also weiß ich schon mal wo der steht.
Dann suche ich mir eine Größe pro Speicherblock aus.
Sagen wir 4kB.
Aus meinem Multiboot bekomme ich die Größe meines RAM.
Wenn ich nun die Größe des RAMs durch meine Speicherblockgröße teile, müsste ich an sich die Anzahl an Blöcken bekommen, oder?
Achso, wo bekomme ich den Multiboot her?
Ich weiß, den erstellt GRUB aber wo liegt der?
Gruß
rizor
Mal sehen, ob ich es verstanden habe.
Wenn ich mein System starte, packt GRUB meinen Kernel ja an eine Stelle, die ich festgelegt habe.
Also weiß ich schon mal wo der steht.
Dann suche ich mir eine Größe pro Speicherblock aus.
Sagen wir 4kB.
Aus meinem Multiboot bekomme ich die Größe meines RAM.
Wenn ich nun die Größe des RAMs durch meine Speicherblockgröße teile, müsste ich an sich die Anzahl an Blöcken bekommen, oder?
Achso, wo bekomme ich den Multiboot her?
Ich weiß, den erstellt GRUB aber wo liegt der?
Gruß
rizor
517
Lowlevel-Coding / Bitmaps
« am: 05. December 2008, 00:12 »
Nabend,
ich bin gerade dabei mir einen Speichermenager für den physikalischen Speicher zu schreiben.
Habe mir überlegt, dass ich erst mal Bitmaps verwende (wirken für mich recht einfach).
Nun wollte ich mal fragen, ob ich alles richtig verstanden habe.
Bei einem x86-System habe ich zwei Möglichkeiten meinen Speicher zu mappen, 4kB und 2MB, oder?
Dann definiere ich mir einfach einen Speicherbereich in meinem Kernel, der meine Bitmap darstellt.
Da habe ich ja eine Endadresse meines Kernels, die ich als Offset interpretiere, oder?
Also wenn ich Bit2 in meiner Bitmap allozieren möchte, wähle ich einfach die Endadresse meines Kernels und addiere da dann dann die Größe drauf.
Dann habe ich doch meine Page-Adresse, oder?
Beim Speicher freigeben, habe ich die Adresse ziehe davon mein Kernelende ab und teile durch die Größe, oder?
Dann müsste ich doch das Bit haben.
Hoffe, dass das soweit stimmt.
Nun habe ich aber ein Problem.
Ein Teil des Speichers ist ja durch das BIOS und ein Teil durch meinen Bootloader (in meinem Fall GRUB) belegt.
Habe auch im LOST-Projekt gesehen, dass ich mit einer Multiboot-Struct das alles abfragen kann.
Nun habe ich aber das Problem, dass ich nicht weiß wie groß die Pages sind und wie groß mein RAM ist.
Wie bekomme ich raus, was genau belegt ist und wie groß mein RAM ist?
Die Größe des RAMs muss ich ja kennen um meine Bitmap-Größe zu bestimmen.
Außerdem schreibe ich gerade einen 32-Bit-Kernel.
Das bedeutet, dass ich ja durch die Adressierung eingeschränkt bin.
Sollte ich meinen Kernel-Bereich auch mappen?
Wenn ja, wie?
Wie muss ich denn darauf reagieren, wenn ich mehr als 3GB-RAM habe?
Muss ich dann von Hand darauf achten, dass ich nicht versuche mehr Speicher zu Adressieren?
Dann habe ich noch eine Frage zum Kernel-Aufbau.
Bevor ich meinen Speichermanager aufrufe, rufe ich erst den GDT udn IDT auf, die belegen doch auch schon Platz auf dem RAM, oder habe ich das falsch verstanden?
Die Adressen muss ich ja auch kennen.
Hoffe ich konnte die Fragen so formulieren, wie ich sie meine
.
Danke für eure Hilfe.
Gruß
rizor
ich bin gerade dabei mir einen Speichermenager für den physikalischen Speicher zu schreiben.
Habe mir überlegt, dass ich erst mal Bitmaps verwende (wirken für mich recht einfach).
Nun wollte ich mal fragen, ob ich alles richtig verstanden habe.
Bei einem x86-System habe ich zwei Möglichkeiten meinen Speicher zu mappen, 4kB und 2MB, oder?
Dann definiere ich mir einfach einen Speicherbereich in meinem Kernel, der meine Bitmap darstellt.
Da habe ich ja eine Endadresse meines Kernels, die ich als Offset interpretiere, oder?
Also wenn ich Bit2 in meiner Bitmap allozieren möchte, wähle ich einfach die Endadresse meines Kernels und addiere da dann dann die Größe drauf.
Dann habe ich doch meine Page-Adresse, oder?
Beim Speicher freigeben, habe ich die Adresse ziehe davon mein Kernelende ab und teile durch die Größe, oder?
Dann müsste ich doch das Bit haben.
Hoffe, dass das soweit stimmt.
Nun habe ich aber ein Problem.
Ein Teil des Speichers ist ja durch das BIOS und ein Teil durch meinen Bootloader (in meinem Fall GRUB) belegt.
Habe auch im LOST-Projekt gesehen, dass ich mit einer Multiboot-Struct das alles abfragen kann.
Nun habe ich aber das Problem, dass ich nicht weiß wie groß die Pages sind und wie groß mein RAM ist.
Wie bekomme ich raus, was genau belegt ist und wie groß mein RAM ist?
Die Größe des RAMs muss ich ja kennen um meine Bitmap-Größe zu bestimmen.
Außerdem schreibe ich gerade einen 32-Bit-Kernel.
Das bedeutet, dass ich ja durch die Adressierung eingeschränkt bin.
Sollte ich meinen Kernel-Bereich auch mappen?
Wenn ja, wie?
Wie muss ich denn darauf reagieren, wenn ich mehr als 3GB-RAM habe?
Muss ich dann von Hand darauf achten, dass ich nicht versuche mehr Speicher zu Adressieren?
Dann habe ich noch eine Frage zum Kernel-Aufbau.
Bevor ich meinen Speichermanager aufrufe, rufe ich erst den GDT udn IDT auf, die belegen doch auch schon Platz auf dem RAM, oder habe ich das falsch verstanden?
Die Adressen muss ich ja auch kennen.
Hoffe ich konnte die Fragen so formulieren, wie ich sie meine
.Danke für eure Hilfe.
Gruß
rizor
518
OS-Design / Re: Frage zu meinem Kerneldesign
« am: 03. December 2008, 20:50 »
Achso.
Mal sehen ob ich es richtig verstanden habe.
Wenn einer meiner Prozesse einen Interrupt anmelden möchte, meldet er sich beim Scheduler der das dann alles verwaltet oder wie?
Ich weiß, dass ich ein wenig zu weit denke, aber ich möchte es in der Gesamtheit verstehen.
Aber wotu brauche ich dann die riesen Menge an möglichen IDT-Plätzen?
Mal sehen ob ich es richtig verstanden habe.
Wenn einer meiner Prozesse einen Interrupt anmelden möchte, meldet er sich beim Scheduler der das dann alles verwaltet oder wie?
Ich weiß, dass ich ein wenig zu weit denke, aber ich möchte es in der Gesamtheit verstehen.
Aber wotu brauche ich dann die riesen Menge an möglichen IDT-Plätzen?
519
OS-Design / Re: Frage zu meinem Kerneldesign
« am: 03. December 2008, 16:22 »
Wie kann ich mir das mit den Interrupts dann vorstellen?
Ich kann meine Prozesse dann in die Liste eintragen wenn ich möchte, oder?
Welche Art von Interrupt muss es denn dann sein, damit ich den Prozess anspreche?
Kann ich damit dann Abhängigkeiten realisieren, oder wie?
Also dass ein Prozess das Ergebnis eines anderen braucht um zu beginnen.
Ist das der Sinn dahinter?
Wenn ja, woher weiß mein Kernel, dass der Prozess auf den gewartet werden muss fertig ist?
Ich kann meine Prozesse dann in die Liste eintragen wenn ich möchte, oder?
Welche Art von Interrupt muss es denn dann sein, damit ich den Prozess anspreche?
Kann ich damit dann Abhängigkeiten realisieren, oder wie?
Also dass ein Prozess das Ergebnis eines anderen braucht um zu beginnen.
Ist das der Sinn dahinter?
Wenn ja, woher weiß mein Kernel, dass der Prozess auf den gewartet werden muss fertig ist?
520
OS-Design / Re: Frage zu meinem Kerneldesign
« am: 03. December 2008, 00:36 »
Danke für eure Antworten.
Da sind mir jetzt noch ein paar Fragen in den Kopff geschossen:
- Wenn ich die Module vom Grub laden lasse, wie kann ich sie dann laden? (Wie sieht der "Befehl" aus)
- Sollte ich wirklich alle Interrupts deaktivieren?
Es kann doch ganz gut sein, wenn ich zum Beispiel IO-interrupts zulasse, damit ich zur Laufzeit bestimmte Prozesse vom wait in den ready-zustand schieben kann.
Das kann doch nur besser für die Laufzeit der Prozesse sein, oder?
Dabei drängt sich mir gleich noch eine neue Frage auf.
Ich habe 256 mögliche Interrupts die der Prozessor zuordnen kann, der PIC hat aber nur 15 Kanäle (Pic1 & Pic2).
Das bedeutet, dass ich meine Kanäle nicht eindeutig definieren kann.
Woher weiß ich nun, wenn aus Leitung 11 ein Interrupt kommt, von wem der Interrupt geworfen wurde?
Das ist ja extrem wichtig.
Danke für eure Hilfe.
gruß,
rizor
[edit]
könnt ihr mir eine seite nennen, die ext2 oder ext3 gut erklärt?
Muss ja wissen, wie ich den treiber zu schreiben habe.
Da sind mir jetzt noch ein paar Fragen in den Kopff geschossen:
- Wenn ich die Module vom Grub laden lasse, wie kann ich sie dann laden? (Wie sieht der "Befehl" aus)
- Sollte ich wirklich alle Interrupts deaktivieren?
Es kann doch ganz gut sein, wenn ich zum Beispiel IO-interrupts zulasse, damit ich zur Laufzeit bestimmte Prozesse vom wait in den ready-zustand schieben kann.
Das kann doch nur besser für die Laufzeit der Prozesse sein, oder?
Dabei drängt sich mir gleich noch eine neue Frage auf.
Ich habe 256 mögliche Interrupts die der Prozessor zuordnen kann, der PIC hat aber nur 15 Kanäle (Pic1 & Pic2).
Das bedeutet, dass ich meine Kanäle nicht eindeutig definieren kann.
Woher weiß ich nun, wenn aus Leitung 11 ein Interrupt kommt, von wem der Interrupt geworfen wurde?
Das ist ja extrem wichtig.
Danke für eure Hilfe.
gruß,
rizor
[edit]
könnt ihr mir eine seite nennen, die ext2 oder ext3 gut erklärt?
Muss ja wissen, wie ich den treiber zu schreiben habe.