Thema: API: Wie realisiert man es am besten?

[RedEagle]

Hi
Ich beschäftige mich seit einigen Tagen mit der API meines Kernels. Leider bekomme ich mit jeder Lösung 1000 neue Probleme und alles ist irgendwie extrem aufwändig.

Meine bisherige Lösung, bzw. Lösungsansatz

Ein Prozess ruft eine C-Funktion auf - bsp.: APITEST("hello world");
APITEST selber ist aber in assembly realisiert - in APITEST werden nun die Argumente, welche sich ja auf dem Stack befinden, wiederum an eine neue Stackadresse kopiert (Als Argument der 0xFF-ISR), um dann int 0xFF aufzurufen.

Die "0xFF-ISR" erwartet die Argumente auf dem Stack, und ist ebenfalls in asm geschrieben, nur die Funktions-Nummer kommt per eax

Von dieser ISR geht es nun weiter: Die Argumente werden wieder an eine neue Position im Stack kopiert, und dann die eax - entsprechende C-Funktion aufgerufen.

kurz: C -----> ASM --int0xFF--> ASM -----> C

Dabei gibt es nun ein Probleme - der String "hello world" befindet sich im virtuellen Speicher des Prozesses, die Funktion zum ausgeben des Strings benötigt aber den virtuellen Speicher des Kernels (gut, das geht vielleicht auch ohne Kernelspeicher, aber spätestens bei Dateiarbeiten muss ich mit dem Speicher des Kernels arbeiten)

Lösung: ich wechsle auf das PD des Kernels und mappe die Page, auf der sich der String befindet.

Problem: Was ist, wenn mehrere Prozesse das gleiche vor haben - ich kann also nicht die Page an der selben virtuellen Adresse mappen, wie sie im Prozess liegt - dadurch muss ich also alle Pointer die ich bekomme umrechnen.


Meine Frage nun:
Wie realisiere ich eine API am besten, die ich sowohl von asm, als auch C aus gut ansprechen kann, und wie regle ich das mit den Speicherräumen?

[kevin]

Die meisten Systeme haben sowas wie ein PD des Kernels überhaupt nicht. Der Kernel läuft dann immer im Kontext des aktuellen Prozesses und damit ist das Problem mehr oder weniger gelöst.

Wenn du das nicht machen willst, musst du wohl oder übel temporär mappen und die Pointer umrechnen. Der tyndur-Kernel hat für solche temporären Mappings eine Funktion, die eine physische Adresse und eine Länge nimmt, die passenden Pages an irgendeine freie Stelle mappt und einen Pointer auf die entsprechende virtuelle Adresse (nicht die Startadresse der Page, sondern gleich mit passendem Offset) zurückgibt. Das gleiche dann entsprechend fürs Freigeben.

[RedEagle]

Dadurch das mein Kernel ein eigenes PD hat, spare ich mir die PDs der Prozesse anzupassen, wenn ich im Kernel zum Eigenbedarf Speicher reserviere.
In die PDs der Prozesse werden dann nur die Speicherbereiche gemappt, die für Taskwechsel nötig sind, der Heap des Kernels ist für sie ja unwichtig. Nach dem erstellen eines Prozesses braucht dann im Bereich des Kernelspeichers nichts mehr am PD geändert werden.

Ich werd's dann wohl mit dem rummappen machen.

Das Problem mit dem zahlreichen kopieren der Argumente löse ich, indem ich nur noch die Adresse weiterreiche, an der die Argumente liegen.

Danke für die Antwort

[XanClic]

Ich persönlich hab es so gelöst, dass ganz am Anfang alle Page Tables des Kernelspaces (also für 0xC0000000 bis 0xFFFFFFFF bei mir) in dessen Page Directory eingetragen werden. Wenn ein neuer Prozess erstellt wird, dann wird dieser Bereich (also die oberen 256 Einträge) von diesem "Ur-Page-Directory" in das Page Directory des neuen Prozesses kopiert. Wenn nun irgendwas im Kernelspace gemappt wird, dann trägt man das in einer dieser Page Tables ein und das ändert sich dadurch in allen Prozessen gleichzeitig (weil dort ja überall die gleichen Page Tables eingetragen sind), ohne dass man deren Page Directory verändern müsste.

[kevin]

Außer man braucht eine neue Page Table.

Oder legst du gleich 256 Page Tables an und verschenkst das Megabyte halt, wenn es nicht genutzt wird?

[XanClic]

Wie geschrieben, ich lege von vornherein alle 256 Page Tables an. Jo, dann ist das Megabyte weg. Aber ich bin sowieso nicht drauf aus, ein besonders speicherschonendes OS zu schreiben.

Der Vorteil ist eben, dass ich mich nicht mit dem Updaten der Page Directories plagen muss.

Genauer gesagt sind es btw 255 Page Tables, weil ich den Platz der letzten Page Table für das Page Directory nehme (also verbrauche ich den Platz von 0x300000 bis 0x400000 für diese "initialen" Pagingstrukturen, dabei sind die ersten 4 kB für das initiale Page Directory (das dann später das des Idle Tasks ist) und die restlichen 255 * 4 kB für diese Page Tables. Also bleiben die 4 kB ab 0xFFFFF000 ungemappt.

[kevin]

Na hoffentlich kommt Erik nicht in diesem Thread vorbei, der würde dir was erzählen.

[erik.vikinger]

Hallo,

Na hoffentlich kommt Erik nicht in diesem Thread vorbei, der würde dir was erzählen.

Was soll das heißen?
So oder so ähnlich würd ich das auch machen wenn ich ein Flat-Memory-OS entwickeln würde. Schade ist nur das man so keine 4MB-Pages für den Kernel nutzen kann.

Aber ich bin sowieso nicht drauf aus, ein besonders speicherschonendes OS zu schreiben.

RAM kostet ja heutzutage fast nichts mehr. Die Menge an RAM-Bytes pro Euro wächst zur Zeit jedenfalls schneller als die CPU-MIPS pro Euro.


Grüße
Erik

[kevin]

Echt? Ich bin von dir gewohnt, dass du schon etwas auf Effizienz achtest, und hätte erwartet, dass das auch auf Speicherverbrauch erweiterbar ist.

In tyndur machen wir es dynamisch statt gleich alle Page Tables anzulegen, und das führt nicht zu größeren Verrenkungen.

[erik.vikinger]

Hallo,

Echt? Ich bin von dir gewohnt, dass du schon etwas auf Effizienz achtest, und hätte erwartet, dass das auch auf Speicherverbrauch erweiterbar ist.

Es handelt sich einmalig um exakt ein einziges MByte, von dem man einen gewissen Teil so wieso braucht, ich denke das ist verschmerzbar. Es sei den man möchte nen alten 386 mit nur 4 MByte RAM auch als Zielplattform unterstützen.

In tyndur machen wir es dynamisch statt gleich alle Page Tables anzulegen, und das führt nicht zu größeren Verrenkungen.

Das heisst wenn der Kernel mehr Speicher braucht werden alle PDs aktualisiert? Ich bin ehrlich, das währ mir zu viel Arbeit in Relation für das eine bisschen Speicher.


Grüße
Erik

[kevin]

Kisten mit 4 MB RAM zu unterstützen ist auch schon schwierig genug ohne eins davon direkt zu verschenken.

Wobei da ein Monolith wohl wieder im Vorteil wäre.

[bluecode]

In tyndur machen wir es dynamisch statt gleich alle Page Tables anzulegen, und das führt nicht zu größeren Verrenkungen.

Das heisst wenn der Kernel mehr Speicher braucht werden alle PDs aktualisiert? Ich bin ehrlich, das währ mir zu viel Arbeit in Relation für das eine bisschen Speicher.

Nur wenn eine neue Page Table gebraucht wird, werden die PDs aktualisiert. Das passiert alle 4MB mal. Also praktisch garnicht.

[erik.vikinger]

Hallo,

Das heisst wenn der Kernel mehr Speicher braucht werden alle PDs aktualisiert? Ich bin ehrlich, das währ mir zu viel Arbeit in Relation für das eine bisschen Speicher.

Damit meinte ich das es mir zu viel Tipp-Arbeit währe überhaupt Code für das aktualisieren aller PDs zu erstellen.
Der einzigste Grund für diesen Aufwand den ich akzeptieren würde währe die Verwendung von 4MByte Pages für den Kernel, das kann immerhin etwas (manchmal auch mehr) an Performance bringen.

.... Das passiert alle 4MB mal. Also praktisch garnicht.

Bei einem Micro-Kernel, dessen bescheidener Speichereigenbedarf zur Laufzeit offensichtlich auch nur wenig wächst, muss man doch kein ganzes Giga-Byte vorsehen. Da reichen doch bestimmt 64MByte, und damit 64kByte an Page-Tables, völlig aus. Schon ist die sogenannte Verschwendung wieder in einem Maß wo es sich wahrlich nicht lohnt extra Code dagegen zu schreiben. Als positiver Nebeneffekt wächst der virtuelle Adressraum für die Programme auf satte 3,75GByte an.


Grüße
Erik

[ehenkes_]

Wieviel MB benötigen eure OS denn so als Minimum? Bei PrettyOS liegt der Wert so um 20 MB.

[kevin]

Was gehört denn bei dir zum Minimum? Das Standardimage von tyndur bootet im qemu mit 5 MB bis in eine Shell, mit 6 MB kann man sogar kedit noch starten.

Aber wenn man es drauf anlegt, dürfte man auch mit weniger auskommen können: Nur eine virtuelle Konsole, Netzwerk weglassen und solche Sachen... [edit: Ich hab mal testweise liballoc gepatcht, jetzt reichen auch 4 MB für die Shell]

[RedEagle]

12MB für den kernel (3 4MB-Pages), darauf kommt dann der heap
Ich würd bei mir mal auf ~16MB schätzen, wobei das schon extrem knapp werden kann.


Da der thread grad wieder in Gebrauch ist schildere ich mal mein derzeitiges vorgehen bei der API:
Wie XanClic empfohlen hat, habe ich den kernel-speicher in alle Prozesse gemapped. Meine pageverwalltung arbeitet quasi nur mit virtuellen Adressen - sodass ich für Kernel und Prozesse die selben Funktionen verwenden kann.
Ich habe dem VMS in 3 teile unterteilt, GLOBAL (hier liegt u.a. der Kernel samt Heap), LOCAL (hier liegen die pages die nur für einen Prozess zugreifbar sein müssen) und einen dritten Bereich in dem die PT's und das PD gemapped wurde (für die pageverwaltung)

Zur Vereinfachung der pageverwaltung habe ich zudem festgelegt, dass wenn mehr als 4MB reserviert werden sollen, dieses in 4MB-Pages getan wird. Braucht man also 6MB bekommt man 2 4MB Pages.
Ist vom speicherverbrauch vielleicht nicht sehr effektiv, aber dafür ist es 1. Schneller, 2. Einfacher und dadurch Stabieler.

Bei der API habe ich mir eine liste gebaut, in der ich einfach nur neue Funktionen einfügen muss, So wie es bei týndur wenn ich mich nicht irre.

[XanClic]

Wieviel MB benötigen eure OS denn so als Minimum?

Aktuell komme ich bei paloxena3 mit 7 MB in eine Shell, aber das heißt nichts, weil noch nicht viel da ist.

[kevin]

Wofür haut ihr denn alle den ganzen Speicher raus? Ich dachte bisher immer, schon tyndur sei verschwenderisch, aber bisher sieht es nicht danach aus, dass andere Systeme mit weniger auskommen.

[XanClic]

Na ja, ich reserviere das erste MB komplett, das zweite für den Kernelcode, das dritte für den Stack, das vierte für Kernel-Page-Directory und -Page-Tables und ab dem fünften kommt dann die Bitmap für den PMM. Und danach kommt dann der dynamisch allokierte Rest.

[erik.vikinger]

Hallo,


ihre redet doch alle "nur" von einem OS mit einer Shell. Brauchen Eure OS dafür wirklich so viel Speicher?
Ich sehe ja ein das die PD u.ä. einiges an physischen Speicher fressen aber doch nicht so viel. Ich hab mal große Programme für einen DOS-Extender (der ja was Speicherverwaltung/IRQ-Management usw. angeht einem OS schon recht nahe kommt) entwickelt und der hat kaum 400kBytes für sich selbst verbraucht. Errinnert sich den keiner mehr an das goldene Motto "640kByte sind genug für ...."?


Grüße
Erik