Thema: RPC und Treiber

[bitmaster]

Hi,

ich bastle gerade mal wieder an den Trieibern und am RPC rum.

Also ich rufe mit einem Anwendungsprogramm die Funktion GetDate der Bibliothek time.lib auf. Jetzt soll die time.lib mit dem Treiber der Real Time Clock komunizieren und die Daten per RPC beschaffen. Aber um eine Message zu senden ist die Angabe der PID des Real Time Clock Treibers erforderlich, welche nicht immer gleich ist (logisch). Wie komme ich jetzt an der PID?

danke!!!

[kevin]

Indem du sie an irgendeiner zentralen Stelle hinterlegst. Beispiel LOST: init ist immer PID 1. Dort registrieren sich alle Treiber mit ihrem Namen. Wer auf einen Treiber zugreifen will, fragt init nach der PID. Der Kernel wäre aber sicher auch ein geeigneter Ort.

[bitmaster]

Mit welchen Namen denn? Nicht den Dateinamen, oder?

[kevin]

Der stimmt zufällig überein (ich nenne die Datei für den Service "floppy" halt normal nicht "network" oder so...), aber grundsätzlich nicht. Wie das im Detail regelst, ist aber deine Sache.

[bitmaster]

Ah OK. Was floppy aber mit network zu tun haben soll habe ich noch nicht herausgefunden. Na ja, dann sage ich auf jeden Fall schon mal danke. Kann aber sein, dass ich demnächst noch ein paar Fragen stellen werde. Ich hoffe du/ihr nehmt mir das nicht übel. tschau

bitmaster

[bluecode]

Ich hab zur IPC nicht die Prozessnummern verwendet, sondern bei mir hat jeder Prozess der IPC machen wollte einen message port erstellt, welcher eine eindeutige ID hatte. Für bestimmte Sachen hatte ich dann feste IDs, sodass man bei den festen IDs wusste was sich dahinter verbirgt. Siehe hier (Zeile 123) für eine Liste der fixen IDs.

[jgraef]

Bei mir gibt es eine Headerdatei mit den Portnummern der einzelnen Server. Jeder Server registriert seine eigene Portnummer im Kernel. Der Prozess muss nun nur gucken welche Portnummer der Server hat und über einen Syscall bekommt er aus der Portnummer die PID.

Das mit der Headerdatei ist vielleicht nicht so optimal, sie ist auch eigentlich nur als Stütze gedacht, da man sich die Portnummern nicht so gut merken kann.

[bitmaster]

Dann suche ich noch genauere Vorschläge zum Aufbau einer Message. Und wie sollte der Empfänger auf eine Message reagieren, die für ihn unbekannt ist?

danke!!!

[bluecode]

Dann suche ich noch genauere Vorschläge zum Aufbau einer Message.

Art/Typ der Message + Parameter der Message
evtl. brauchst du noch eine ID zum unterscheiden welche Respose auf welchen Request passt.

Und wie sollte der Empfänger auf eine Message reagieren, die für ihn unbekannt ist?

Wenn die Art der Message unbekannt ist, dann einfach ein Message mit einem Fehlercode zurückschicken.

[bitmaster]

OK. Also könnte eine ganz vereinfachte Message z.B. folgenden Aufbau haben:

db 5 ;Typ z.B. 5 = Speicher soll auf einen Sektor geschrieben werden
times: 512 db 0 ;Speicher der geschrieben werden soll

Und dann SendMessage die Parameter der Adresse der Nachricht, den Empfänger mittels PID und die Nachrichtengröße (hier z.B. 513) übermitteln.

?

bitmaster

[bluecode]

db 5 ;Typ z.B. 5 = Speicher soll auf einen Sektor geschrieben werden

Ein Byte ist evtl. etwas wenig für die Messagetypen, va. wenn du sie so konkret machst wie "Sektor schreiben".

Ich persönlich finde das Adressieren mittels PID nicht so toll, da es Multithreading komplett außer Acht lässt. Aber man kann das natürlich so machen, klar.
Worüber du evtl. nachdenken solltest ist, wie die Antwort auf die Anfrage auszusehen hat und was passiert wenn mehrere Anfragen versendet wurden und wie man dann die Antworten zuordnet.

[bitmaster]

Du meinst, dass man eine Zeichenkette als Typ angeben sollte und kein Byte/Word/DWord/QWord? Aber dann müsste ja zusätzlich auch ein Byte für die Größe der Zeichenkette vorhanden sein.

Ja ich bin am überlegen ob ich immer nur eine Message senden lassen soll oder so viele bis der RAM voll ist.

bitmaster

[bluecode]

Du meinst, dass man eine Zeichenkette als Typ angeben sollte und kein Byte/Word/DWord/QWord? Aber dann müsste ja zusätzlich auch ein Byte für die Größe der Zeichenkette vorhanden sein.

Nein, ich meine, dass ein byte zu wenig ist. Das ermöglichst nur 256 verschiedene Nachrichtentypen.

Ja ich bin am überlegen ob ich immer nur eine Message senden lassen soll oder so viele bis der RAM voll ist.

hä? Ich meine nur, dass du dir überlegen sollst, wie ein Programm das zwei oder mehr Nachrichten (z.B. lese Sektor 1 und lese Sektor 2) versendet ("gleichzeitig") und danach auf Antwort wartet herausfindet, welche der Antworten auf "Lese Sektor 1" und welche auf "Lese Sektor 2" passt. Wie gesagt, so etwas wie ein Message-ID Feld mag da zu überlegen sein, so verwendet, dass die Antwort die gleiche ID wie die Anfrage haben muss. D.h. dass die Anfrage "Lese Sektor 1" z.B. ID 100 hat und "Lese Sektor 2" die ID 200 hat. Wenn die Antworten dann eintreffen, kannst du anhand der ID entscheiden welche Antwort zu welcher Anfrage passt (also die Antwort mit ID 100 passt zu "Lese Sektor 1" und ID 200 passt zu "Lese Sektor 2").

[bitmaster]

Ah so, jo das muss ich mir auch noch überlegen. Aber jetzt gucke ich BAAAAAAAAYEEEEEEEEEERN. 

[bitmaster]

Ah so, jo das muss ich mir auch noch überlegen. Aber jetzt gucke ich BAAAAAAAAYEEEEEEEEEERN. 

Na ja, dann nehme ich halt ein QWORD anstatt BYTE. So, ich progge dann mal.

[bitmaster]

Da ist mir noch was eingefallen. Ähm sollte der Empfänger bereits vorher Speicher für die zu empfangende Message reservieren oder soll das die GetMessage machen? Denn sonst müsste man ja vorher erstmal schauen wie groß die Message ist.

danke!!!

[kevin]

Weißt du, was mir gerade auffällt, bitmaster? Wenn man 08/15-Stringfunktionen, die sowieso überall gleich sind, kopiert, ist das aus deiner Sicht eine Schandtat, weil man ja sein eigenes OS schreibt. Da, wo es aber wirklich interessant wird, wo man was denken muß und wo sich Betriebssysteme wirklich unterscheiden können, fragst du hier nach jedem Detail, damit du es genau nachprogrammieren kannst.
Kleiner Widerspruch?

Einzelne Nachrichten vorher reservieren wird schwierig, wenn du nicht weißt, wie groß die Nachricht wird. Aber man kann sich da vieles ausdenken.

[bluecode]

Folgende Möglichkeiten fallen mir da so ad hoc ein:

• Die Nachrichten von dem versendenden Prozess in einem speziellen Bereich allozieren lassen und diesen Bereich dann in den Page-Directories/-Tables aus dem sendenden Prozess austragen und den empfangenden eintragen. Dabei spart man sich das rumkopieren im Kernel, d.h. es ist va. schnell für große Nachrichten und wenn man das noch ein bisschen erweitert, dann hat man shared-memory gleich fast kostenlos dazu. (Das verwende ich, offensichtlich )
• Empfänger holt erst die Paketgröße, dann alloziert er, dann holt er die eigentliche Nachricht.
• Empfänger hat eine maximale Nachrichtenlänge
• Kernel ist dafür zuständig, dass Speicher in einen speziellen Bereich des Prozesses gemappt wird und eingehende Nachrichten dort hinkopiert werden. Bei getMessage gibts dann nur einen Pointer dahin. Bisschen problematisch ist das evtl aber: Was passiert wenn mehrere Nachrichten eingehen (wo wird hinkopiert? wie wird die Nachricht wieder freigegeben? fragmentiert das? etc...)

Taljeth spricht mir aus der Seele, dankeschön.

[bitmaster]

Taljeth spricht mir aus der Seele, dankeschön.

Jo, mir auch, dankeschön.

Hmm... dann müsste ich nach dem Empfang der Nachricht den Speicher explizit wieder frei geben, wenn ich die Nachricht nicht mehr benötige, sonst verbraucht der Prozess ja evtl. ziemlich viel Speicher (bei vielen weiteren Nachrichten).

Nojo donn wollen wor mo proggen gohon.

danke!!!

[bluecode]

dann müsste ich nach dem Empfang der Nachricht den Speicher explizit wieder frei geben [...]

Momentan hast du aber echt lichte Momente, Hut ab.