Aktuelle Bugs: Wer ihn findet, darf ihn behalten!

[Xin]

Dieses Casten ist gefährlich. Nimm einen C++ Compiler und verwende static_cast<>(), das ist, was Du hier tun möchtest. Der Compiler wird dann meckern, weil Du das hier nicht getan hast.
Der C-Cast erlaubt eine derartige Unterscheidung nicht.

Naja, auf C++ wollte ich eigentlich nicht umsteigen.
Der Kernel selbst soll möglichst in C geschrieben werden

C++ kann schneller als C sein.

Ich habe den Cast nun einfach entfernt bzw die Notwendigkeit dazu entfernt (aus dem Pointer in den Parametern einfach ein unsigned int gemacht^^).

Die exakte Typverwendung ist da eh viel besser.

Das, was ich gemacht habe, könnte man so umschreiben:

Müsste eigntl einen General Protection Fault auf jedem normalen PC hervorrufen.
Ich übernehme keine Haftung, falls es jemand ausprobiert.
Anmerkung: 0xF4 ist der Assembler Befehl "hlt", der die CPU anhält. Dürfte nur der Kernel des laufenden Betriebssystems ausführen können...

Du trainierst für Buffer Overflows, hmm?

[Dirty Oerti]

C++ kann schneller als C sein.

Ja, aber um das ganze Projekt auf C++ umzustellen und die Feinheiten zu lernen, die es bei der Verwendung von C++ in der LowLevelProgrammierung gibt brauche ich soviel Zeit, die ich wohl besser dann in Optimierungen stecke

Die exakte Typverwendung ist da eh viel besser.

Ist in diesem Fall schwer, ich verwende ints anstelle von int* um Probleme beim Umstieg auf Paging zu beheben.
Ich versuche aber, das ganze in einem recht einheitlichen Schema zu halten.

[Xin]

C++ kann schneller als C sein.

Ja, aber um das ganze Projekt auf C++ umzustellen und die Feinheiten zu lernen, die es bei der Verwendung von C++ in der LowLevelProgrammierung gibt brauche ich soviel Zeit, die ich wohl besser dann in Optimierungen stecke

Einige Sachen kannst Du in C nicht so sicher optimieren, wie in C++.
'inline' wäre für Deinen Kernel eine wichtige Optimierung, die Du in C nur mit dem Präprozessor nachbilden kannst.

Die exakte Typverwendung ist da eh viel besser.

Ist in diesem Fall schwer, ich verwende ints anstelle von int* um Probleme beim Umstieg auf Paging zu beheben.
Ich versuche aber, das ganze in einem recht einheitlichen Schema zu halten.

Welches Problem kannst Du haben? Immerhin ist ein (int *) auf LowLevelEbene gleichbedeutend mit (int)

[Dirty Oerti]

Inline funktioniert doch auch unter C..?
Man muss es dem GCC nur sagen, dass er Inlining betreiben soll
Bis jetzt lief Inlining...vorallem in den Kritischen Abschnitten...allerdings darauf hinaus, dass ich es wieder rückgängig machen musste, da das "zu viel" Optimierung für die LowLevel-Ebene zu sein scheint.

Welches Problem kannst Du haben? Immerhin ist ein (int *) auf LowLevelEbene gleichbedeutend mit (int)

Das Problem liegt dort, das die Zeiger sowohl mit aktivierten Paging als auch mit deaktiviertem verwendet werden müssen. Benutzt man einen "Zeiger in den phys. Speicher" wenn Paging an ist, kann man irgendwo landen.
Deshalb verwende ich ints, die nur an genau den Stellen in ein (int *) gecastet werden, an denen auch ein Zugriff erlaubt/notwendig ist.

Typtechnisch ist ein (int) gleich einem (int *), der Inhalt wird sich aber dennoch unterscheiden...
Immerhin enthält das eine eine Adresse, das andere den Wert.

[Dirty Oerti]

Ok, was zum Thema:

Ich habe nun ein, denke ich, soweit funktionierendes Multitasking...

Mit einer Frequenz von 100Hz wird der IRQ0 aufgerufen und wechselt den Task, wenn seine "Lebensdauer" gleich 0 ist. Ist das nicht der Fall, wird die Lebensdauer des Tasks um 1 reduziert und der Task weiterlaufen gelassen.

Nun habe ich 2 Tasks:

KernelTask: Gibt Punkte aus, hat eine Lebensdauer von 5 (die natürlich immer bei einem Wechsel wieder auf 5 gesetzt wird).
IdleTask: Gibt rote Striche aus, hat eine Lebensdauer von 1 (die auch bei einem Wechsel wiederhergestellt wird.)

Ab in den Emulator, es funktioniert auch alles.
Nun aber etwas komisches:
Bochs und Qemu scheinen sich nicht einig zu sein:

bochs-ausgabe_kernel.jpg

qemu-ausgabe_kernel.jpg

Das verstehe ich nun sowas von gar nicht...

[Xin]

Ich würde den echten PC fragen und mich auf den **Emulator** konzentrieren, der näher dran liegt.

[Dirty Oerti]

Ich würde den echten PC fragen und mich auf den **Emulator** konzentrieren, der näher dran liegt.

Gute Idee
*Neustarten gehe*

Ok...Qemu liegt näher dran, aber trotzdem haben beide Recht
Erklärung:

"First think, then start debuging"

Der Punkt wird nicht vom KernelTask geschrieben, sondern wird jedesmal bei einem TaskSwitch geschrieben.
Nun sind sowohl Qemu als auch der echte PC deutlich schneller als bochs.
Folge daraus ist, das zwischen den einzelnen TaskSwitchs viel mehr Arbeit geleistet werden kann, folglich können auch mehr Striche gezeichnet werden bevor ein Punkt durch einen Taskwechsel stattfindet.


Lasse ich den KernelTask den Punkt ausgeben, dann nähern sich die beiden Emulatoren schon an.
Bochs ist halt einfach langsamer...

[Dirty Oerti]

Was zur Zeit nicht geht:

Dem neuen Task ein eigenes Directory zuweisen.

Das ist in dem Sinne schlecht, da nicht alle Tasks das Kerneldirectory benutzen können...
Im Moment ist es aber so...

Problem ist, dass, sobald ich ein Directory (mit der bisherigen Funktion) klonen möchte, Paging abgeschaltet werden muss. Ist das Paging aus, habe ich das Problem, dass ich den Stack nicht benutzen darf, was in der jetzigen Funktion aber passiert. Das führt dann bei bochs dazu, dass sich alles aufhängt

Ich muss mir nun also eine Möglichkeit überlegen, neue Directories zu erstellen
Hat jemand dazu eine Idee?

MfG
Daniel

[Xin]

Was zur Zeit nicht geht:

Dem neuen Task ein eigenes Directory zuweisen.

Das ist in dem Sinne schlecht, da nicht alle Tasks das Kerneldirectory benutzen können...
Im Moment ist es aber so...

Problem ist, dass, sobald ich ein Directory (mit der bisherigen Funktion) klonen möchte, Paging abgeschaltet werden muss. Ist das Paging aus, habe ich das Problem, dass ich den Stack nicht benutzen darf, was in der jetzigen Funktion aber passiert. Das führt dann bei bochs dazu, dass sich alles aufhängt

Warum musst Du den Stack benutzen?

Ich muss mir nun also eine Möglichkeit überlegen, neue Directories zu erstellen
Hat jemand dazu eine Idee?

Statische Variablen verwenden oder den Stack auf eine statische Adresse umbiegen?

[taljeth]

Problem ist, dass, sobald ich ein Directory (mit der bisherigen Funktion) klonen möchte, Paging abgeschaltet werden muss.

Das halte ich für ein Gerücht. Paging schaltet man einmal an und dann bleibt es an. Vermutlich sind einfach deine Funktionen nicht geeignet. Pseudocodemäßíg würde ich sagen, Klonen eines PD läuft so:

Code: Alles auswählen

phys_new_pd = get_phys_page();
new_pd = map_page(phys_new_pd);
memcpy(new_pd, old_pd, 0x1000);
unmap_page(new_pd);

Fertig. Das Unmappen ist dabei optional, wahrscheinlich brauchst du das PD noch im Speicher.