[hydrixOS] : Re: Virtuelle Maschinen
- From: Friedrich Graeter <webmaster@xxxxxxxxxxx>
- To: hydrixos@xxxxxxxxxxxxx
- Date: Mon, 03 Feb 2003 12:47:17 +0100
Chris Burkert schrieb:
>>
>>Die virtuellen Prozessoren sind Teil des Betriebssystemkerns und müssen
>>nicht zwingend Interpreter sein, sie könnten theoretisch auch Programme
>>übersetzen (was ein erwünschtes Endziel wäre), bzw. Programme, die von
>>der "Host"-CPU verstanden werden, direkt ausführen lassen.
>
>
> Das ist mir klar. Mir kam nur die Idee, das es für eine
> plattformunabhängige Architektur unnötig und ressourcenverschlingend
> ist, einen Interpreter auf einem VP noch oben drauf zu setzen. Wieso
> nicht gleich als VP implementieren.
>
Also ein Interpreter kann natürlich gleich als VPC implementiert werden
- ich wollte nur einige Unterschiede zwischen einer normalen VM und
einem VPC nennen :-).
> Ein Image ist wie bei Java eine Ansammlung von 32 Byte breiten Befehlen.
> Es ist also quasi ein Programm. Woher weiß jetzt Hydrix welcher VP
> diesem Bytecode zugeteilt wird und kann man dem VP auch noch zusätzlich
> Informationen mitteilen (Optionen, Umgebungsvariablen, ...) ?
Jeder Prozess besitzt eine VPC-ID. Wenn der VPC drankommt, wird die
Verarbeitungsroutine des VPCs vom Kern heraus direkt aufgerufen. Der
Scheduler von HydrixOS ist kein typischer i386-Scheduler, der zwischen
verschiedenen Tasks wechselt, sondern er ruft lediglich den jeweiligen
VPC eines Threads auf. Die VPCs sind wiederum dafür verantwortlich nach
der abgelaufenen Zeit zum Kern zurückzukehren (da sie selbst Teil des
Kerns sind, wird dies vorausgesetzt - ev. kann sich dies aber auch ändern).
Die Laufzeit-Informationen des VPCs zu jedem Thread werden in einem
Status-Bereich gespeichert, über die der VPC die Kontrolle hat. Direkt
können die VPCs für einen Thread (oder auch Prozess) nicht zusätzlich
mit Informationen versehen werden - allerdings wäre ein solcher
Mechanismus sicher realisierbar. Tatsächliche Umgebungsvariablen u.ä.
sind ebenfalls jenseits des Kerns realisiert.
> - ANSI C Compiler
Da der VPC Teil des Kerns ist, benötigt man eigentlich nur einen
C-Compiler auf der Plattform, auf der man den Kern kompiliert. Der
Kernel selbst ist für gcc 3.2 ausgerichtet und ich konnte die aktuelle
Version vollständig bisher unter Windows (DJGPP) und Linux kompilieren.
> - Allokieren von Speicher
Der Kernel bietet nur Funktionen zur Verwaltung eines virtuellen
Adressraums. Die interne Strukturierung des Adressraums (malloc, free)
erledigt der Prozess (oder eine API-Bibliothek im Prozess) selbst (in
der API-Bibliothek für HydrixOS-Programe sind diese Funktionen in der
Datei alloc.c umgesetzt). In der nächsten Version kann er zusätztlich
auch wirklich die Speicherseiten über den Pageing-Dämon wieder freigeben
und reservieren. Die Frage ist, ob man die Speicherverwaltung von
Smalltalk theoretisch auch in einer Programmbibliothek unterbringen kann
(notfalls könnte auch der VPC diese Aufrufe in die Bibliothek
durchführen) oder müsste diese fest im VPC verankert sein?
> - Dateizugriff
Das Dateisystem ist unter HydrixOS in einen Server gekapselt, allerdings
ist dieser noch nicht implementiert und das Protokoll dazu entsteht gerade.
> - Ein Zeitgeber
Auch hier müsste erst noch der Treiber implementiert werden. Wobei
sowohl Dateisystemserver, als auch Treiber vom Vorhandensein des
Pageing-Dämons abhängig sind (ich hoffe, dass bis Version 0.2.6 der
Zugriff auf jenen im Kernel realisiert ist und die Entwicklung des
Dämons beginnen kann).
>
> Wenn die ersten 4 Punkte vom OS möglich sind, ist es erst einmal kein
> Problem, Squeak zu portieren. Richtig Spaß macht es aber erst mit
> Netzwerkfähigkeiten.
Das Problem ist, dass für die letzten zwei Punkte noch die Infrastruktur
im System fehlt. (Der HydrixOS-Kernel ist ja ein Quasi-Mikrokernel - er
enthält nur Prozessverwaltung, Threadverwaltung, IPC über Nachrichten,
Kontrolle des externen Pageing-Dämons, die VPCs und den Scheduler.)
> Gut! Ich werde mich mal mehr in eure Doku einlesen und mich melden, wenn
> ich etwas tun kann oder etwas aus meiner Sicht anderes gelöst werden könnte.
Okay, danke!
cu
FG
--
HydrixOS Developers Mailing List
Administration: webmaster@xxxxxxxxxxx
Archive: //www.freelists.org/archives/hydrixos
Other related posts:
