Thema: Kerneldesign Milestone 1

[mastermesh]

http://commos.overgames.de/wiki/index.php/Kernel

Bitte hier im Forum kommentieren.

[hannibal]

ad Prozessverwaltung/Scheduling: d.h. ein ' externes ' modul ist dann fuer das eigentliche laden der prozesse verantwortlich?
wie soll denn das funktionieren den scheduler als eigenen prozess zu machen? der scheduler ist doch im grunde nur eine kombination aus interrupts, oder hab ich da was falsch verstanden?

ansonsten, sehr huebsch

lg, hannibal

[DDR-RAM]

ad Prozessverwaltung/Scheduling: d.h. ein ' externes ' modul ist dann fuer das eigentliche laden der prozesse verantwortlich?

ja

wie soll denn das funktionieren den scheduler als eigenen prozess zu machen? der scheduler ist doch im grunde nur eine kombination aus interrupts, oder hab ich da was falsch verstanden?

Der trägt sich als Taskgate in die IDT ein. Daher, hat eigenes TSS und so.
Das auch immer in der GDT vorhanden sein muss. Er besitzt, nicht wie die anderen Prozesse/Threads noch irgendwelche prozess/thread-spezifische Zusatzinformationen. Hoffe, das ist verständlicher.

ansonsten, sehr huebsch

Danke

lg, hannibal

MfG
DDR-RAM

[T-Head]

Hi,

kleine Frage: Wie is eigentlich der Akrtuelle stand? Also, was wurde jetzt schon gemacht? Wirds irgendwann wieder ein Coder, ... Treffen in irgend einenm Chat geben? ...

[mastermesh]

Hab bereits recht lange nichts mehr von den Entwicklern gehört, aber die IDT-Verwaltung scheint soweit fertig zu sein, DDR-RAM ist mit der Prozessverwaltung auch recht weit (meinte, er müsste nur noch adjustieren)... von urx hab ich leider gar nichts gehört, er wollte sich um die GDT kümmern.

EDIT: urx hat sich gemeldet. Er konnte aus bestimmten Gründen in letzter Zeit nicht coden, doch er meinte, er wäre bald fertig.

Wenn Milestone 1 fertig und stable ist, müssen wir uns so langsam Gedanken um die API, die Treiber und das VFS machen.

[Svenska]

Mit dem Zeitscheibenverfahren... ich finde ein Prioritätsbasiertes System nuetzlicher. Drei Stufen wuerden imho reichen, Wichtig, Normal, Unwichtig. Ein wichtiger Prozess kriegt doppelt so viel Zeit, ein unwichter die Hälfte der Zeit wie ein normaler, einfach wichtig => nochmal reinschalten, normal => weiterschalten, unwichtig => jedes zweite Mal ueberspringen. Ansonsten kann man ja mit Zeitscheiben arbeiten.
Sodass man im Prinzip ein Programm "nach hinten" stellen kann, damit es den Rechner nicht blockiert oder nach vorne, um eine bestimmte Aufgabe zu beschleunigen (zB der Taskmanager von Win ist immer höhere Priorität).

Svenska

[DDR-RAM]

Mit dem Zeitscheibenverfahren... ich finde ein Prioritätsbasiertes System nuetzlicher. Drei Stufen wuerden imho reichen, Wichtig, Normal, Unwichtig. Ein wichtiger Prozess kriegt doppelt so viel Zeit, ein unwichter die Hälfte der Zeit wie ein normaler, einfach wichtig => nochmal reinschalten, normal => weiterschalten, unwichtig => jedes zweite Mal ueberspringen. Ansonsten kann man ja mit Zeitscheiben arbeiten.
Sodass man im Prinzip ein Programm "nach hinten" stellen kann, damit es den Rechner nicht blockiert oder nach vorne, um eine bestimmte Aufgabe zu beschleunigen (zB der Taskmanager von Win ist immer höhere Priorität).

Svenska

Ich versuche sogar prioritätsbasierendes zu implementieren.
worst case O(n) = log2 n

Arbeitet mit sinkenden prioritäten des laufenden threads, so das nieder priorisierte threads auchmal rankommen können.

Ich hatte nur wie (vielleicht auch nicht ) gesagt die letzten 10 Tage an einem Spieleprojekt gearbeitet, wo die erste version gestern fertig sein musste, jetzt habe ich wieder ca. 2 Jahre dafür
Ich werd CommOS und das ding parallel machen.
Aber es hatte halt gerade höhere Prioritität
und jetzt versuche ich schnellstmöglich der prozessverwaltung erste lauffähige version fertigzustellen.

MfG
DDR-RAM