Eigenes OS?
-
@+gjm+: Danke für die Analyse, kannst Du Dir den aktuellen Code nochmals anschauen?
Da waren leider doch noch einige plötzlich aufpoppende Fehler mit memset() anstelle k_memset in ordered_array usw., aber dennoch klappt es noch nicht richtig. Habe auch in den headern os.h, ... noch etwas Ordnung (hoffentlich) geschafft.
Ich schiebe den aktuellen Code mal hoch, vielleicht hat jemand die entscheidende Idee zum Durchblick. Vor lauter blöden Adressen blicke ich nicht mehr durch.
create_heap() hilft auch noch nicht. Bin nicht völlig sicher, ob das in ckernel.c sein muss. Keine Ahnung, wo der heap momentan erzeugt wird.Sehe vor lauter Wald die Bäume nicht mehr, aber den Code dürfte ich jetzt soweit funktionsfähig haben. Könnte sich das bitte mal jemand anschauen (fehlen nur noch die richtigen Parameter, sicher bin ich aber noch nicht)?
http://www.henkessoft.de/OS_Dev/Downloads/20_analyze_failure.zipEDIT1: hier sieht die frames Anzahl (mit createheap(0x300000,...) z.B. 3674124) nun besser aus.
es läuft ohne sti() durch bis zum Umschalten auf Paging, dann kommt der reset, kann noch an falschen Parametern liegen:
http://www.henkessoft.de/OS_Dev/Bilder/Fehlersuche_PAGING_HEAP.PNGEDIT2: das Problem liegt in create_heap(...)
Da ist etwas im hinteren Teil instabil. Auch mit Kontroll-Prints passieren da merkwürdige Sachen auf dem Bildschirm, noch dazu nicht gleich reproduzierbar.
..heap in create_heap(...) 0000B1D0h
heap->index in create_heap(...) 00200000h
header_t_less_than in create_heap(...) 0000A90Ch
start in create_heap(...) 00280000h
start ... after alignment check 00281000hAbsturz?
Manchmal kommt auch noch die nächste Zeile. ???
Nach der letzten Ausgabe springt der Cursor nach (0,0)! keine Ahnung warum?
Dann erfolgt Reset.Ohne sti() bekommt man mehr Infos (s.u. seaprater Post)
Bitte um weitere Unterstützung, damit wir das Thema didaktisch angehen können.
Ich werde mich mal zur Ablenkung auf die Key Queue als nächste Aufgabe konzentrieren.
Diesen Paging/Heap Mist werde ich etwas schieben. Dieser verschachtelte Code mit den kreuz und quer verteilten Parametern nervt mich langsam.
Der Code müsste für ein Tutorial entflochten und klar strukturiert werden.
Vielleicht kennt/hat jemand etwas Besseres?Problemliste:
- Beep() geht nicht (speaker)
- Paging/Heap zum Laufen bringenKurzfristige Taskliste:
- KeyQueue aufbauen (als ersten Schritt kann man die Daten ja über eine Auswerte-Funktion in ckernel.c abholen und darstellen)
- Paging/Heap entflechten (erst Heap und Demo, dann Paging für Multitasking)Auf jeden Fall danke an alle, die mich unterstützen.
-
Letzter Stand:
http://www.henkessoft.de/OS_Dev/Downloads/20_analyze_failure.zip ( ohne sti() )#include "os.h" int main() { //... //sti(); //ansonsten Absturz im hinteren Teil von create_heap(...) kheap = create_heap(0x200000, 0x400000, 0x500000, 0, 0); paging_install(); //TEST
Bildschirmausdruck:
http://www.henkessoft.de/OS_Dev/Bilder/Fehlersuche_PAGING_HEAP_1.PNGPlease help.
-
- deleted -
-
Fehler gefunden, ein kleines & zuviel vor 'end'. Man sucht immer an der falschen Stelle. Naja, zumindest beschäftigt man sich intensiv mit dem Code. Das hat seine Vorteile.
Nun endlich lauffähig: die vereinfachte Paging-Version ohne create_heap(...):
http://www.henkessoft.de/OS_Dev/Downloads/22.zipMit Bitte um Vorschläge zur Vereinfachung und Demo-Nutzung des Codes,
z.B. Page Fault ...
Bezüglich Didaktik denke ich darüber nach:
*Wie kann man Paging zum Anfassen/Experimentieren darstellen?
Welche Vorteile haben wir nun davon?
...
*
-
So nun habe ich auch die komplexe Variante mit create_heap() zum Laufen gebracht.
@abc.w: bringt sogar eine echte page_fault_exceptionhttp://www.henkessoft.de/OS_Dev/Downloads/20_Paging_Heap.zip
So, nun geht's mir wieder besser.
... und den Blick nach vorne:Problemliste:
- Beep() geht nicht (speaker)
- Scroll in video.c schneidet erstes Zeichen in neuer Zeile ab (??)Kurzfristige Taskliste:
- Paging optimieren (für Tutorial)
- Was macht man nun mit dem Heap? - Einfache Anwendungssteuerung? (was zuerst?)
- KeyQueue aufbauen
- Anwendung auf KeyQueue zugreifen lassen
- Multitasking
-
da gibt's doch 'ne funktion 'create_heap'. die musste natürlich vorher aufrufen.
@+fricky: Wie Du siehst ist Paging und Heap hier entkoppelt, geht also zum Glück ohne dieses create_heap(...) via kmalloc(...).
-
Erhard Henkes schrieb:
da gibt's doch 'ne funktion 'create_heap'. die musste natürlich vorher aufrufen.
@+fricky: Wie Du siehst ist Paging und Heap hier entkoppelt, geht also zum Glück ohne dieses create_heap(...) via kmalloc(...).
ok, aber irgendwie musste dem heap ja sagen, wo sein speicher ist.
Erhard Henkes schrieb:
- Was macht man nun mit dem Heap? - Einfache Anwendungssteuerung? (was zuerst?)
na, den user-programmen (und dem kernel, also z.b. treibern usw) die funktionen malloc(), realloc() und free() zur verfügung stellen.
Erhard Henkes schrieb:
- Anwendung auf KeyQueue zugreifen lassen
hier haste für sowas einen lock-free FIFO: http://svn.akop.org/psp/tags/fuse/0.9.0.1/sound/sfifo.c
so'n FIFO kann z.b. von einer interrupt-routine (oder anderen task) gefüllt und während des lesens müssen keine interrupts gesperrt werden. ich hab' ihn schon mal benutzt: funzt perfekt.
-
Danke für den Link, aber ich möchte es mit einer Datenstruktur analog BDA probieren, sieht momentan so aus:
os.h:/* This defines the operatings system common data area */ #define KQSIZE 100 // size of key queue typedef struct oda { // Hardware Data //... // Key Queue UCHAR KEYQUEUE[KQSIZE]; // circular queue buffer UCHAR* pHeadKQ; // pointer to the head of valid data UCHAR* pTailKQ; // pointer to the tail of valid data UCHAR KQ_count_read; // number of data read from queue buffer UCHAR KQ_count_write; // number of data put into queue buffer }oda_t; // operatings system common data area oda_t ODA; extern oda_t* pODA;
util.c (später vielleicht os.c):
oda_t* pODA = &ODA; void initODA() { int i; for(i=0;i<KQSIZE;++i) pODA->KEYQUEUE[i]=0; // circular queue buffer pODA->pHeadKQ = pODA->KEYQUEUE; // pointer to the head of valid data pODA->pTailKQ = pODA->KEYQUEUE; // pointer to the tail of valid data pODA->KQ_count_read = 0; // number of data read from queue buffer pODA->KQ_count_write = 0; // number of data put into queue buffer }
keyboard.c
void keyboard_handler(struct regs* r) { UCHAR KEY = ScanToASCII(); if(KEY) { *(pODA->pTailKQ) = KEY; ++(pODA->KQ_count_write); if(pODA->pTailKQ > pODA->KEYQUEUE) { --pODA->pTailKQ; } if(pODA->pTailKQ == pODA->KEYQUEUE) { pODA->pTailKQ = (pODA->KEYQUEUE)+KQSIZE-1; } } //... }
Test in ckernel.c:
//... initODA(); printformat("KQ: %x TAIL: %x HEAD: %x", pODA->KEYQUEUE, pODA->pTailKQ, pODA->pHeadKQ); settextcolor(2,0); int y=6; while(TRUE) { sleepSeconds(10); if(y>24) y=24; set_cursor(0,++y); printformat(" 10 sec: "); printformat("TAIL: %x HEAD: %x WRITE: %i ", pODA->pTailKQ, pODA->pHeadKQ, pODA->KQ_count_write); printformat("TAILCONTENT: %c %i HEADCONTENT: %c %i\n", *(pODA->pTailKQ),*(pODA->pTailKQ),*(pODA->pHeadKQ),*(pODA->pHeadKQ)); };
************************************************
* Welcome to PrettyOS 0.06 *
* Paging is activated *
************************************************
KQ: 0000A1A4h TAIL: 0000A1A4h HEAD: 0000A1A4h10 sec: TAIL: A1A4h HEAD: A1A4h WRITE: 0 TAILCONTENT: 0 HEADCONTENT:
10 sec: TAIL: A207h HEAD: A1A4h WRITE: 1 TAILCONTENT: 0 HEADCONTENT: a
10 sec: TAIL: A206h HEAD: A1A4h WRITE: 2 TAILCONTENT: 0 HEADCONTENT: a
10 sec: TAIL: A205h HEAD: A1A4h WRITE: 3 TAILCONTENT: 0 HEADCONTENT: a
10 sec: TAIL: A204h HEAD: A1A4h WRITE: 4 TAILCONTENT: 0 HEADCONTENT: a
10 sec: TAIL: A1FEh HEAD: A1A4h WRITE: 109 TAILCONTENT: g 103 HEADCONTE
NT: a 970xA207 = 0xA1A4 + 0x64 (KQSIZE) - 1
passt also alles. Den Tasten-Release (KEY == 0) habe ich unterdrückt, so dass nur ein Zeichen pro Tastenanschlag in die KQ gelangt.Ich möchte diesen Mechanismus komplett selbst durchziehen, weil ich das derart low-level noch nicht gemacht habe, bin durch die Standard Template Library verhätschelt.
Über Lesen aus der KQ und Interrupts habe ich mir noch keine Gedanken gemacht.
Wie geht man mit einem buffer full, also (pODA->KQ_count_write - pODA->KQ_count_read)>100 um. Da ich die Zähler momentan leichtsinnig in UCHAR definiert habe, kommt es auch noch zu einem Überlauf. Das lässt sich sicher durch ULONG in den Griff bekommen, aber prinzipiell ist das Problem dadurch nur in die weite Ferne geschoben. Es soll ja Leute geben, die ihren Rechner nie ausschalten. Bei PrettyOS ist das fast garantiert.Wo sollte das Lese-Programm, also das alte:
restore_cursor(); switch(KEY) { case KINS: break; case KDEL: move_cursor_right(); putch('\b'); //BACKSPACE break; case KHOME: move_cursor_home(); break; case KEND: move_cursor_end(); break; case KPGUP: break; case KPGDN: break; case KLEFT: move_cursor_left(); break; case KUP: break; case KDOWN: break; case KRIGHT: move_cursor_right(); break; default: printformat("%c",KEY); // the ASCII character break; } save_cursor();
nun eigentlich hin? Der User will doch Zahlen und Buchstaben sehen, wenn er tippt. Zumindest als Demo.
Soll ich das als getchar() in keyboard.c realisieren und in ckernel.c mal als demo in der while-Schleife (klares "Polling") laufen lassen oder habt ihr bessere Ideen?
-
Ich habe das zunächst als k_checkKQ_and_print_char() umgesetzt, um didaktisch an unsere bisherige - von Nobuo T kritisierte - "Schreibmaschine" in keyboard_handler(...) anzuknüpfen.
Test in ckernel:
UINT c=0; while(TRUE) { if( k_checkKQ_and_print_char() ) { ++c; if(c>79) { c=0; settextcolor(4,0); printformat("\nT: %x H: %x WRITE: %i Read: %i ", pODA->pTailKQ, pODA->pHeadKQ, pODA->KQ_count_write, pODA->KQ_count_read); printformat("*T: %c %i *H: %c %i\n", *(pODA->pTailKQ),*(pODA->pTailKQ),*(pODA->pHeadKQ),*(pODA->pHeadKQ)); settextcolor(2,0); } } }
jkdfhsdjkhgksjhkjdhkjdfshjkdsfhgjkhjghdfjkghjkdfhgdjkfhkdjfhgkdjfhgkjdfhjkdfhgjk dfhgjkdfhksdfhksdahfksdajhfkjsdhfksdjhfksdajhfasdkhfjkasdhfkasjdfhkjasdhfksladjh faskdjlhfkjhsadkjfhkjasdhfjkasdfhkajsdhfjkasdfhkjasdhfjkasdhfjkasdhfjkasdhfjkasd hfjkhfjkasdhfjksdhfkjahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj jjjjjjjjjjjjjjjjjjjjjjjjjjjjkkkkkkkkkkkkkkkkkkkKKKKKKKKKKKKKLAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA T: 0000A2DAh H: 0000A2DAh WRITE: 640 Read: 640 *T: j 106 *H: j 106 T: 0000A2EDh H: 0000A2EDh WRITE: 720 Read: 720 *T: A 65 *H: A 65
Test und Reaktion (welche?) auf BufferFull/Overrun fehlt noch.
Die Pfeiltasten links/rechts kommen nicht mehr durch.
Was man wirklich mit den Infos in der KeyQueue machen will, hängt sehr von der konkreten Anwendung ab. Ich frage mich momentan, wie man mit den Sondertasten sinnvoll umgehen sollte. Als Flags in der ODA wie bei der BDA machen sie keinen Sinn, weil man nicht weiß, zu welchem Zeichen sie gehören. Aber das lässt sich alles leicht anpassen. Vielleicht hat jemand eine glänzende Idee oder gute Erfahrungen mit eigenen OS.Ich schieb das Programm oben mal hoch, wenn jemand mit dem Code spielen will:
http://www.henkessoft.de/OS_Dev/Downloads/22a.zipBaut man eine Verzögerungsschleife ein, so kommt Schreiben/Lesen so ab 100 Millisekunden (Warteschleife für ms habe ich nun in timer.c ergänzt) aus dem Gleichklang: http://www.henkessoft.de/OS_Dev/Downloads/22b.zip
jksdghkdfjhgkskdfjhgkjsdfhgkjsdfhgskjdfhkhjhgdfjkhgdfkjhgkjdfhgkjdfhgkdfjhgkjdfh gkfdhgkdfhgkdfhgkdfhgkdfhgkdfjhgkdfhgkdfhgkfhkjdshgkjsdfjjjjjjjjjjjjjjjjjjjjjjjj jjjjJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAh WRITE: 662 Read: 640 *T: A 65 *H: A 65 T: 0000A2E0h H: 0000A30Dh WRITE: 765 Read: 720 *T: A 65 *H: A 65
Bleiben die Fragen, wie groß muss KQ sein und wie geht man mit einem Overrun um? (früher hat es da gepiepst ).
-
Bezüglich der Interpretation von Scancodes habe ich folgende interessante Gliederung gefunden:
http://www.toasteros.net/
..
-
Erhard Henkes schrieb:
Bleiben die Fragen, wie groß muss KQ sein und wie geht man mit einem Overrun um?
einfach das älteste zeichen überschreiben (overrun ignorieren). daten von der tastatur kannste als veraltet ansehen, wenn lange keiner drauf zugegriffen hat. der buffer kann auch ziemlich klein sein.
-
+fricky schrieb:
der buffer kann auch ziemlich klein sein.
jup. afair nur 10 zeichen bei MS-DOS. und keiner hats gemerkt.
-
Ja, ich denke auch, dass ein Puffer für Tastatureingaben eher max. 20 Zeichen haben sollte, denn es wirkt - siehe Beispiel mit Warteschleife oben - extrem komisch, wenn da nach dem Tippen noch fast 100 Zeichen aus der Queue auf dem Bildschirm eintrudeln.
-
Erhard Henkes schrieb:
...extrem komisch, wenn da nach dem Tippen noch fast 100 Zeichen aus der Queue auf dem Bildschirm eintrudeln.
vor allem brauchste dir keine gedanken darum zu machen, wie du den fall handlest, wenn die queue voll ist und neue daten eintrudeln. das problem kriegste erst bei datenquellen, wo nix verloren gehen darf.
-
Noch ein Nachtrag zum Thema C vs C++:
Lowlevel Magazin ( http://lowlevel.brainsware.org/old/files/lowlevel_4.pdf ):
..
-
^^objective-c bringts auch nicht so: http://kerneltrap.org/mailarchive/linux-kernel/2007/11/30/463283
aber es gibt auch das: http://de.wikipedia.org/wiki/Singularity
(wobei der low-level code aber in C geschrieben wurde).
-
..
-
..
-
Erhard Henkes schrieb:
Diese Funktion ist ebenfalls ein merkwürdiges Konstrukt:
page_t* get_page(ULONG address, UCHAR make, page_directory_t* dir) { address /= PAGESIZE; // address ==> index. ULONG table_index = address / 1024; // ==> page table containing this address if (dir->tables[table_index]) // table already assigned { return &dir->tables[table_index]->pages[address%1024]; } else if(make) { ULONG phys; dir->tables[table_index] = (page_table_t*) k_malloc( sizeof(page_table_t), 1, &phys ); k_memset(dir->tables[table_index], 0, PAGESIZE); dir->tablesPhysical[table_index] = phys | 0x7; // 111b meaning: PRESENT=1, RW=1, USER=1 return &dir->tables[table_index]->pages[address%1024]; } else return 0; }
hier ist eigentlich nur das letzte 'else' überflüssig.
-
(ULONG)-1 sollte man hier besser 0xFFFFFFFF schreiben?
Ich habe übrigens von James Molloy schriftlich die Freigabe, seinen - aus meiner Sicht nicht uninteressanten - Sourcecode als Basis für eigene Entwicklungen im Rahmen des Tutorials nutzen zu dürfen. Man muss ja nicht immer wieder das Rad neu erfinden, wie man so schön sagt.
Gerade die Verwendung des Bitsets beim Paging ist effizient. ..