Thema: Systemcalls

[GhostCoder]

Hiho,

ich würde mal gern wissen in welcher Weise ihr Systemcalls benutzt?
Also, wie z.B. Linux einfach über int 0x80 mit subcodes, oder anders?

Ich frage, weil ich grad meinen Kernel neucode für folgendes System:
Es gibt nur 4 "richtige" (also auf dem x86 über int's) Systemcalls, die da wären:

int Open(int iPid,int iBufferSize,void **ppvBuffer);
int SendMessage(int iProcess,int iMessage);
int GetMessage(struct MSG *psMsg,int iWait);
int Close(int iProcess);

Mit Open wird eine Verbindung zwischen 2 Prozessen aufgebaut, d.h. Speicher für einen Puffer geholt und in den virtuellen Addressraum der beiden Prozesse gemappt, damit während des Schickens kein langwieriges mappen mehr stattfinden muss. In den Buffer können dann halb beide Prozesse schreiben und per Send/Get Message Nachrrichten schicken und empfangen. Mit Close wird dann der Puffer freigegeben.

Der Vorteil hier ist, dass z.B. ein "Window Server" im Netz läuft und die Clienten darauf zugreifen. Auch bleibt der Kernel dadurch extrem klein, weil alle Treiber eigene Prozesse sind. Aber auch z.B. das vfs kann ein eigener Prozess sein. Dadurch kann jeder Teil des Betriebssystems ohne Probleme im Betrieb neugestartet werden usw. Auch kann es "theoretisch" über timeouts unmöglich sein, den pc abzuschießen.

Was sagt ihr dazu?

MfG GhostCoder

[kleiner]

Werden die Nachrichten dann nach einem eigenen Protokoll codiert?
Und was mich etwas wundert ist, dass Du zwar einen int-Wert sendest, aber ein struct MSG erhälst. Müsste dann nicht bei GetMessage auch ein int reichen?
Und wie erfährt das andere Programm, dass es eine Nachricht erhalten hat. Wird das über ein Signal gelöst?
Also, wenn das wirklich so funktioniert Hut ab. Das wäre dann wohl ein wahrer Exo-Kernel.

[GhostCoder]

Hiho,

zur struct MSG:
In der Struktur stehen nicht nur die Message(int) sondern auch die Pid des Senders, der gesharte Buffer und noch andere Kleinigkeiten, je nach Bedarf.

Zum Nachrichten erhalten:

Code: [Auswählen]

while(1)
{
      GetMessage(&Msg,1);
}
GetMessage schickt den aktuellen Prozess auf sleep, d.h. er wird erst wieder ins scheduling einbezogen, wenn eine Nachricht vorliegt.

Mittlerweile arbeite ich aber schonwieder an einem anderen (schnelleren und einfacheren[weniger code]) System. wenn das fertig ist, kann ich es ja bei Interesse ja mal hier posten.

MfG GhostCoder

[mastermesh]

Die Architektur hört sich interessant an. Könntest du evtl. mal den gesamten Quellcode veröffentlichen? Wäre bestimmt für viele Leute nützlich.

[GhostCoder]

Hiho,

sobalt der neue Code fertig ist, kann ich ihn posten, ja.

MfG GhostCoder

[Franz1299]

Das wäre sehr nett von dir ;P

[GhostCoder]

Hiho,

also den Quellcode veröffentliche ich noch nicht (der kommt mir der ersten public version), weil viel von dem Messaging Code hängt auch mit dem Multitasking-, Scheduling- und anderen Code ab.
Hier aber erstmal wie es funzt:

Code: [Auswählen]

// Returns the buffer that is shared by the kernel and the calling process
struct MESSAGE *GetMessageBuffer();

// Send a message to a process
int SendMessage(int iPid,UINT uiMessage);

// Sends the calling process to sleep until a message arrives
void WaitMessage();

// Copies the first message into the message buffer
int GetMessage();
Also, beim erstellen eines Prozesses wird ein sog. MessageBuffer erstellt, in dem immer eine Message gespeichert werden kann. Der MessageBuffer wird dann in den Kernel und Prozess Space gemappt, sodass beide darauf zugreifen können.

WaitMessage setzt den Prozess solange auf sleep (d.h. er wird nicht in scheduling einbezogen -> keine rechenzeit) bis eine Nachricht vorhanden ist.

Mit GetMessage wird die erste Message im MessageQueue(der Warteschlange) in den MessageBuffer kopiert, die Adresse kann sich der Prozess ja über GetMessageBuffer holen.

Und schlussendlich SendMessage, die, man glaub es kaum , eine Nachricht an eine Prozess schickt.

Ich denke bald wird eine Message noch um einen SubCode sowie ein Data UINT erweitert. Darauf lassen sich dann alle "richtigen" Systemcalls ala GetPid(), CreateThread() und sowas (also eigentlich die komplette API) später aufbauen.

So, ich glaube schneller geht eine asyncrone microkernel prozess kommunikation wohl kaum wenn doch lasst es mich wissen...

MfG GhostCoder

[Another Stupid Coder]

Hoert sich sehr gut durchdacht an finde ich respekt

[GhostCoder]

Hiho,

danke, ich hab aber schonwieder was neues *gg
dabei werde ich, denke ich, aber bleiben. hier steht das:
http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&threadm=4a7f52c4.0407230027.3068afc2%40posting.google.com&prev=/groups%3Fhl%3Dde%26lr%3D%26ie%3DUTF-8%26q%3Dalt.os.development%26btnG%3DSuche
( Ich weiß aber nicht, woher der Text aus 2001 (der mit dem vbe) kommt)
Der wesentliche Unterschied zur og. Methode ist eigentlich nur, das SendMessage
und GetMessage nun keine Syscalls mehr sind, da der Prozess ja sowieso
auf den Buffer zugreifen kann, den kompletten Code dafür hab ich auch schon geschrieben, falls jmd Interesse hat...

MfG GhostCoder

[Another Stupid Coder]

Ja