Nachrichten

41

Lowlevel-Coding / Re: Diskettentreiber

« am: 12. November 2009, 08:03 »

Ich hab vor Ewigkeiten mal einen Code dafür geschrieben. Der macht einige Sachen etwas zu kompliziert, und ich hoffe der wirkt abschreckend.

http://jidder.de/stuff/asm-execute-rm-int-from-pm.html <--- nicht klicken, nicht lesen, nicht kopieren, UND NICHT FRAGEN WENN DER NICHT FUNKTIONIERT

Ich beantworte dazu keine Fragen. Kein Witz.

Edit: Willst du eigentlich einen Diskettentreiber oder dich mit esoterischem Code rumschlagen?

So etwas wollte ich auch mal schreiben. *g*
Aufgrund des unnützen Aufwands habe ich das aber dann gelassen (es gibt ja den virtual mode).

42

OS-Design / Re: Von USB-Stick booten

« am: 12. November 2009, 07:48 »

Was auch eine Möglichkeit wäre, ist dass es am Stick liegt...
Es gibt bootable USB-Devices, die eine andere Spezifikation erfüllen. Erfüllt der Stick diese nicht, kann es sein, dass er gebootet wird, es kann allerdings auch sein, dass das BIOS dann Probleme macht... 

43

tyndur / Re: 0.3 - Ideen und Ziele

« am: 11. November 2009, 19:15 »

Ich habe nichts geklont... Ich habe das Webinterface genutzt und da war kein "gfxtest" sichtbar.
 
Geklont habe ich das jetzt so, wie es in der wiki steht:

Code: [Auswählen]

git clone git://git.tyndur.org/tyndur.git

EDIT
Habe nun alles da... Ist das erste mal, dass ich mit git zu tun habe, da ich für mein Projekt ein SVN-Repository am laufen habe...
 
Ich werde dann einfach mal etwas experimentieren. Vielleicht komme ich ja dann auch zu einer einfachen GUI, je nach dem, ob nun schon daran gearbeitet wird oder nicht.
Sollte so etwas bereits in Arbeit sein, werde ich mal schauen, was sich machen läst...

44

Lowlevel-Coding / Re: Verständnisfragen

« am: 11. November 2009, 17:33 »

Ich habe mal in den Code von lightOS rein geschaut...
Hier hatte die Klasse für den PIC, sowie APIC eine Methode "handle_irq". Daraus habe ich geschlossen, dass das getrennt behandelt werden muss. Da ich aber keine Lust habe jedes mal bei einem IRQ zu prüfen, ob denn ein APIC oder ein PIC vorhanden ist, habe ich einen globalen Funktionszeiger angelegt, der dann eben immer aufgerufen wird.
In den entsprechenden Funktionen muss man dann eben prüfen, ob es sich bei dem Interrupt überhaupt um einen IRQ handelt, da PIC und APIC anscheinend zu verschieden sind, als dass ich das mit einem If erledigen könnte:

Code: [Auswählen]

//...
void (*hardware_interrupt_handler)(registers_t*) = 0;
//...void interrupts_handler(registers_t *r)
{
// An error occured
if(r->interrupt_number < 32)
{
video_puts(exception_messages[r->interrupt_number]);
video_puts(" Exception. System Halted!\n");
for(;;);
}

if(r->interrupt_number == 0x80)
{
// handle system call
}

// handle hardware interrupts
if(hardware_interrupt_handler != 0)
hardware_interrupt_handler(r);
}

Ist eben die Frage, was besser ist... die Lösung oben oder die, in der mit einer boolschen Variable geprüft und die entsprechende Funktion aufgerufen wird...

45

tyndur / Re: 0.3 - Ideen und Ziele

« am: 11. November 2009, 07:57 »

Werde ich tun...
Mal so ganz neben bei, gibt es eigentlich schon einen Treiber für die Maus?
 
Und wie sieht es mit dem Stand der gui aus? Anscheinend gibt es ja schon ein Modul hierfür...
 
EDIT
Irgend etwas stimmt nicht...
Ich sehe keinen Ordner "gfxtest", wenn ich diesen aber in der URL angebe, komme ich rein...

46

tyndur / Re: 0.3 - Ideen und Ziele

« am: 10. November 2009, 13:14 »

Ich wollte einfach mal ein bisschen mit den Grafiktreibern unter tyndur experimentieren, also z.B. Bildschirm komplett Blau ausfüllen oder in eine andere Auflösung wechseln oder mal einen Kreis zeichen... 
 
Leider ist es nicht möglich, die Version 0.2.1 zum laufen zu bringen, da unter bochs der Prozess kbc einen Timeout auslöst. Aus dem Grund konnten dann die Prozesse vterm, getterm4 und default nicht gestartet werden...

47

Lowlevel-Coding / Re: Verständnisfragen

« am: 10. November 2009, 13:00 »

Das mit den Aufrufkonventionen wußte ich, aber warum nur i386? Ist das bei einer 64Bit CPU anders?
 
Noch etwas, da ich ja grad bei Interrupts bin. Wenn ich den PIC nehme, mappe ich die IRQs von 32 bis 48. Das ist aber nur der PIC, wie sieht das mit dem local APIC aus? Da sind das ja mehr als nur die 16 IRQs. Muss ich da extra einen speziellen handler für den APIC-Krempel schreiben?
 
Btw. Ich habe mich noch nicht viel mit dem APIC beschäftigt, nur auslesen, ob dieser überhaupt vorhanden ist, und wo die Basisregister im Speicher anfangen...

48

Lowlevel-Coding / Re: Verständnisfragen

« am: 10. November 2009, 08:52 »

Es gibt mal wieder etwas unklares... 
 
Da ich vor kurzem mein System gründlich sabotiert habe und nicht mehr auf meine Daten zugreifen konnte, musste, bzw. muss, ich einige Teile von meinem Betriebssystem nochmals schreiben. Hier bin ich bei folgendem Stück Code hängen geblieben:

Code: [Auswählen]

; Push created stack
mov eax, esp
push eax
; Call C-Function
mov eax, interrupts_handler
call eax
pop eax

Wenn man auf normalem Wege eine C-Funktion in Assembler aufruft (call my_cfunction), so muss man nach dem call esp um 4 erhöhen, damit der Rest danach noch ausgeführt wird.
Bei obiger Implementation, die ich aus einem Tutorial entnommen habe ist das nicht nötig, aber warum? Was passiert genau, wenn der Wert in eax per "call"-instruction aufgerufen wird?

49

Lowlevel-Coding / Re: Größe des Kernels

« am: 03. November 2009, 16:47 »

Nun ja, ich war mir dabei nicht sicher, deshalb der Thread im Offtopic.
 
Anscheinend ist der Kernel so groß, weil ich 255 Assembler-Stubs für die Interrupts habe. Vorher waren das nur 48...
 
So eine Linkermap ist eben doch zu was nützlich. Nun tauchen immer wieder Einträge folgender Art auf:

Code: [Auswählen]

*fill*         0x000000000010001e        0x2 00
.....
 *fill*         0x0000000000100041        0xf 00
.....
 *fill*         0x000000000010105e        0x2 00
Könnte es sein, dass dadurch der Kernel nochmals größer wird, sprich ich was im Linkerscript falsch gemacht habe? Oder ist das normal?
 
Hier ein etwas längerer Auszug:

Code: [Auswählen]

Linker script and memory map

                0x0000000000100000                KERNEL_VMA = 0x100000
                0x0000000000100000                KERNEL_LMA = 0x100000
                0x0000000000000000                KERNEL_VOFFSET = (KERNEL_VMA - KERNEL_LMA)
                0x0000000000100000                . = KERNEL_VMA
                0x0000000000100000                kernel_start_address = .

.text           0x0000000000100000     0x46ee
 *(.text)
 .text          0x0000000000100000       0x1e src/kernel/src/arch/i386/cpu.s.o
                0x0000000000100000                check_cpuid
 *fill*         0x000000000010001e        0x2 00
 .text          0x0000000000100020       0x21 src/kernel/src/arch/i386/start.s.o
                0x0000000000100020                _start
 *fill*         0x0000000000100041        0xf 00
 .text          0x0000000000100050     0x100e src/kernel/src/arch/i386/interrupts.s.o

.... Hier kommen die 255 Stubs ....

 *fill*         0x000000000010105e        0x2 00
 .text          0x0000000000101060       0x10 src/kernel/src/arch/i386/init.c.o
                0x0000000000101060                arch_system_initialise
 .text          0x0000000000101070       0x39 src/kernel/src/arch/i386/apic.c.o
                0x0000000000101070                apic_install
 *fill*         0x00000000001010a9        0x7 00
 .text          0x00000000001010b0        0x6 src/kernel/src/arch/i386/pic.c.o
                0x00000000001010b0                pic_install
 *fill*         0x00000000001010b6        0xa 00



50

Lowlevel-Coding / Re: Größe des Kernels

« am: 02. November 2009, 19:50 »

Nicht wirklich...
Das einzige, was dazu gekommen ist, ist die Sektion für die read-only daten, wie z.B. Strings.
Wenn ich das weglasse, bzw. in den Code-Part mit hinein packe, wird der Kernel nur 4 KB kleiner, was für den Inhalt des Kernels allerdings (in meinen Augen) immer noch zu groß ist.

51

Lowlevel-Coding / Größe des Kernels

« am: 02. November 2009, 19:23 »

Hallo Leute,
ich bin seit einiger Zeit dabei, mein Projekt aufzuräumen, bzw. neu zu schreiben, und habe nun alles schön in Unterordner gepackt, damit eine spätere Portierung leichter fällt. Das ist zumindest das Ziel...
 
Nun hat der Kernel nur eine GDT, IDT, ISRs und ein paar zusätzliche Funktionen, wie z.B. outb oder video_puts. Da das ja nicht sonderlich viel ist, verwundert es mich, dass der Kernel doch bereits jetzt eine Größe von 38 KB hat.
Könnte das an den vielen Unterordnern liegen? Der alte Kernel war nämlich nur ein bissel größer, wenn nicht sogar gleich groß, und konnte wesentlich mehr (Multitasking, System Calls).
 
Muss ich da noch Optimierungsoptionen setzen, oder kann ich auch Optionen weglassen? Die Optionen, die gcc mitgegeben werden, sehen momentan wie folgt aus:

Code: [Auswählen]

-m32 -Wall -Wextra -O3 -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-stack-protector -fno-builtin -I./src/kernel/include -I./src/kernel/include/arch/$(ARCH) -D PAE=$(PAE) -D APIC=$(APIC) -c -o


52

Offtopic / Re: Wird OS-Programmierung in Zukunft ein Kinderspiel sein?

« am: 02. November 2009, 18:29 »

@Chrisitianf
Hu? Sorry, aber ich habe Kontakt mit dem Kerl, der das gemacht hat. Er meinte er würde weiter dran arbeiten 

Das mag sein...
Der letzte Eintrag unter News sagt aber, dass die arbeiten, zumindest offiziell, eingestellt wurden...

53

OS-Design / Re: Von USB-Stick booten

« am: 02. November 2009, 18:26 »

Du musst das Devicenode des Gerätes, also /dev/sdb, angeben, da /dev/sdb1 die erstellte Partition auf deinem Stick ist. Dein Aufruf von grub-install müsste also wie folgt aussehen:

Code: [Auswählen]

/usr/sbin/grub-install --root-directory=/media/VOLUME/ /dev/sdb


54

Offtopic / Re: Wird OS-Programmierung in Zukunft ein Kinderspiel sein?

« am: 02. November 2009, 16:02 »

Nur so nebenbei, das Projekt "Write your OS" wurde am 28. Oktober diesen Jahres eingestellt
 
Beim zweiten Projekt ist anscheinen, wie ich es dem Worklog entnommen habe, nichts weiter geplant, als einfache Realmode-Programme damit zu schreiben:

Mir war letztens langweilig, also hab ich mir mal FASM angeschaut. Dabei ist mir der Gedanke gekommen, dass es doch 100k Noobs gibt, die in allen möglichen Foren kommen mit "ich möchte ein OS programmieren. Ich kann schon HTML/VisualBasic/BB/..." es aber keine Möglichkeit gibt, was bootbares zu schrieben, ohne irgendein Assembler zu beherrschen.

Deswegen hab ich mich dran gesetzt, und begonnen, eine basicartige Programmiersprache zu schreiben, deren Sinn und Zweck es ist, Billigst-"Betriebssysteme" zu schreiben.

55

OS-Design / Re: Interprozesskommunikation (mit CDI) aufbauen

« am: 29. October 2009, 21:51 »

Gut, das heißt also, dass Prozess A beim Init-Prozess per RPC anfragt, ob z.B. ein USB-Treiber (Prozess B) gestartet wurde, läuft und einen RPC-Handler registriert hat.
Gibt es noch andere Ansätze so etwas zu lösen? Mir fällt da gerade leider kein vernünftiger ein...

56

OS-Design / Re: Interprozesskommunikation (mit CDI) aufbauen

« am: 29. October 2009, 18:30 »

Ich habe da mal eine ganz kurze Frage zum RPC-Kram von Tyndur, da ich mir darüber ja auch schon Gedanken gemacht habe, auch wenn ich momentan meilenweit davon entfernt bin, so etwas umzusetzen... 
 
Beispiel:

• Prozess B registriert einen RPC-Handler
• Der Kernel legt irgendwo, z.B. einer Liste, diesen Handler ab, damit er weiß, dass dieser registriert wurde
• Nun kommt Prozess A und möchte, diese RPC-Funktion aufrufen

Was passiert dann? Man muss den Handler heraussuchen, und je nach dem, z.B. eine Nachricht an diesen Handler schicken, damit diese Funktion, nennen wir sie mal "foo" ausgeführt wird.
Woher weiß Prozess A, dass Prozess B überhaupt ausgeführt wird? Können gleiche, bzw. ähnliche, Handler vorkommen, sodass der falsche ausgeführt wird?
Wird ein RPC über die ID des Prozesses B ausgeführt?
 
Gruß Christian

57

Offtopic / Re: Hosen runter! Zeigt eure OS ;)

« am: 16. October 2009, 11:33 »

Ich habe mir StaticOS nochmal angeschaut und bin zu folgendem Schluss gekommen.
 
Das CD-Image funktioniert nicht, es wirft unter bochs immer den Fehler "[ATAPI] - Error 222". Nimmt man allerdings von der Website die Version, in der StaticOS von Diskette gebootet wird und alle anderen Daten von einem CD-Image geladen werden, funktioniert dies mit ein wenig warten einwandfrei.

58

Lowlevel-Coding / Re: Verständnisfragen

« am: 16. October 2009, 09:07 »

Nun ja...
Die Werte (ISR Nummer und Error Code) sind in einer Struktur als unsigned int abgelegt... Ich müsste ja dann eigentlich auch push dword benutzen oder?

59

Lowlevel-Coding / Re: Verständnisfragen

« am: 15. October 2009, 23:07 »

Nun, anscheinend war das einer der Fehler, die nun gelöst sind... 
 
Ich habe in den Makros nun anstatt "push byte %1" nur noch "push %1" stehen, da das byte ja Vorzeichenbehaftet ist, somit bei "int 0x80" immer -128 herauskommt.
Was macht das ganze für einen Unterschied? Nutzt nasm dann den Typ, der gerade passt oder wie sieht das aus?

60

Lowlevel-Coding / Re: Verständnisfragen

« am: 15. October 2009, 12:05 »

Da war ich wohl wieder falsch. Schon blöd bei popa zu schauen, wenn man pusha haben will...
 
Gepusht wird es auf jeden fall, laut manual. Nur wird es nicht wieder zurückgesetzt. Das Zurücksetzen übernimmt dann der/das Mnemonic "iret".