Thema: Wie findet in einem Micro-Kernel-OS ein Programm den richtigen Service?

[erik.vikinger]

Hallo,


wir haben in der letzten Zeit ja reichlich über die Implementierung von IPC diskutiert aber eine Frage ist da für mich immer noch nicht ganz klar:
Wie findet ein Programm den richtigen Port/Message-Target/sonstwas um darüber die gewünschten Dienste in Anspruch zu nehmen?
In einem Micro-Kernel-OS sind ja VFS, TCP, UDP oder Console getrennte Services da müssen die Programme ja immer den richtigen finden.

In meinem OS möchte ich das so lösen das diese Infos bei der Prozesserstellung immer mitgegeben werden. Die libc kümmert sich darum das diese Infos dem nativen CreateProcess mitgegeben werden und die libc holt diese Infos auch im neuen Prozess aus den Parametern raus bevor main aufgerufen wird. Auf diese Art kann ich wahrscheinlich sogar Ressourcen-Vererbung usw. komplett innerhalb der libc abhandeln ohne das die Services (oder gar der Kernel) davon etwas mitbekommen.

Es wäre aber auch möglich das man eine Liste pflegt (möglicherweise direkt im Kernel) in der alle öffentlich erreichbaren Services drin stehen und die Programme sich anhand eines Kriteriums, z.B. ein Name, den gewünschten Service geben lassen.


Wie löst ihr dieses Problem?


Grüße
Erik

[bluecode]

Ich hatte fixe Portnummern für wichtige Services (wie z.B. vfs, pci, tcpip, etc...).

[FlashBurn]

Bei mir hast du die Möglichkeit einem Port einen Namen zu geben und jeden Namen darf es nur einmal geben (ist case-sensitive) oder du übergibst nen leeren String.
Ansonsten hatte ich überlegt die wichtigsten Server über eine Liste im Kernel zu verwalten (wo deren Portnummern drin stehen) und diese Liste kann man sich dann als UserApp holen.

Denn ansich müssen ja nur die Portnummern der Server/Services bekannt sein. Die Treiber (und ähnliche Sachen) registrieren sich dann, genauso wie ein Client, beim Server und nur dieser braucht ja die Portnummern bzw. kann sie gegebenenfalls ja weiterreichen.

[erik.vikinger]

Hallo,

Ich hatte fixe Portnummern für wichtige Services (wie z.B. vfs, pci, tcpip, etc...).

Hm, auch ne Variante. Du schreibst im Präteritum, was benutzt Du denn heute?


Also wir haben bis jetzt feste Nummern und Namen, gibt es noch andere Techniken?


Grüße
Erik

[kevin]

Heute schreibt er kein OS mehr.

In tyndur registrieren sich alle Services bei init mit einem Namen, der dann von anderen Prozessen abgefragt werden kann (init ist immer PID 1, insofern leicht zu finden). Die einzelnen Funktionen eines Service sind auf 8 Zeichen begrenzte Namen, also im Prinzip auch feste 64-Bit-IDs.

[erik.vikinger]

Hallo,

In tyndur registrieren sich alle Services bei init mit einem Namen, der dann von anderen Prozessen abgefragt werden kann (init ist immer PID 1, insofern leicht zu finden).

Aha, also auch Namen.
Ihr versendet die Message direkt an die Process-ID? Bedeutet dass das ein Prozess nur einen einzigen Service anbieten kann?

Die einzelnen Funktionen eines Service sind auf 8 Zeichen begrenzte Namen, also im Prinzip auch feste 64-Bit-IDs.

Was meinst Du mit "einzelnen Funktionen"? Etwa open/read/write/close/.... ? Bei mir sollen alle Funktionen die ein Service anbietet über das selbe Message-Target laufen und erst anhand der Message selber decodiert werden. Natürlich kann ein Prozess mehrere unterschiedliche (oder auch identische) Services unabhängig von einander (über jeweils ein Message-Target) anbieten.


Ich stelle fest das es ohne ein bekanntes konstantes Merkmal wohl nicht geht.


Grüße
Erik

[kevin]

Ihr versendet die Message direkt an die Process-ID? Bedeutet dass das ein Prozess nur einen einzigen Service anbieten kann?

Aus Kernelsicht geht es nur um PIDs, ja. Wenn du dieses Interface als entscheidend ansiehst, gibt es nur einen Service pro Prozess.

Die einzelnen Funktionen eines Service sind auf 8 Zeichen begrenzte Namen, also im Prinzip auch feste 64-Bit-IDs.

Was meinst Du mit "einzelnen Funktionen"? Etwa open/read/write/close/.... ? Bei mir sollen alle Funktionen die ein Service anbietet über das selbe Message-Target laufen und erst anhand der Message selber decodiert werden. Natürlich kann ein Prozess mehrere unterschiedliche (oder auch identische) Services unabhängig von einander (über jeweils ein Message-Target) anbieten.

open/read/write/close sind solche Funktionen, ja. Wie oben gesagt interessiert das den Kernel auch gar nicht, sondern ist auch tatsächlich Teil der Nachricht, aber der Empfänger interpretiert die ersten paar Bytes als Funktionsnummer. Darüber würdest du wohl auch das erreichen, wofür du unterschiedliche Targets hernimmst.

Ich stelle fest das es ohne ein bekanntes konstantes Merkmal wohl nicht geht.

Hm, nichtdeterministische Turingmaschine und dann Guess & Check?

[erik.vikinger]

Hallo,

Wenn du dieses Interface als entscheidend ansiehst, gibt es nur einen Service pro Prozess.

Darf ich daraus schlussfolgern das bei tyndur die Funktionsnummern global eindeutig sind? Das würde es zumindest ermöglichen das hinter einer PID verschiedene Services angeboten werden.

open/read/write/close sind solche Funktionen, ja. Wie oben gesagt interessiert das den Kernel auch gar nicht, sondern ist auch tatsächlich Teil der Nachricht, aber der Empfänger interpretiert die ersten paar Bytes als Funktionsnummer.

Aha, so wollte ich das auch erst machen hab mich dann aber doch dazu entschlossen die "Funktionsnummer" (und auch einen "Returncode") extra zu übergeben (schließlich hab ich für sowas mehr als genug Register). Der Kernel interessiert sich aber auch bei mir nicht dafür um was für einen Service oder um was für eine Funktion es konkret geht.

Darüber würdest du wohl auch das erreichen, wofür du unterschiedliche Targets hernimmst.

Nein, ich wollte schon mehrere Funktionen pro Service (Message-Target) anbieten. In meiner Betrachtung ist z.B. der VFS (mit open/read/....) ein Service der über ein Message-Target eine ganze Reihe an Funktionen anbietet, ebenso wie TCP oder viele andere Services. Es soll aber auch möglich sein das eine Applikation mehrere Services anbietet, aus Effizienzgründen könnte man z.B. TCP und UDP mit in den IP-Prozess integrieren so das dieser eine Prozess mehrere (unabhängige) Dienste parallel anbietet. Die Clients sollen gar nicht merken ob die Services, die sie in Anspruch nehmen, alle aus einem Prozess kommen oder jeder Service aus einem anderen Prozess.


Was die Identifizierung der Services angeht, ich denke ich werde beim "weitersagen" der Message-Target-IDs bleiben.


Grüße
Erik