www.mikrocontroller.net

Forum: PC-Programmierung Kommunikatin zwischen Treibern


Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich bin gerade dabei die Kommunikation zwischen zwei Treibern zu 
implementieren. Zu diesem Thema suche zurzeit einige Beispiele bzw. gute 
Tipps wie man dies am besten realisieren kann! Habe schon von IRPs 
gelesen wollte aber Fragen ob dies die einzige Möglichkeit ist!? Die 
Treiber laufen unter windows.

MFG fresh

Autor: Treiber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Häh? Wieso zwei sollen denn zwei Treiber miteinander kommunizieren?

Ein Treiber kommuniziert mit der Hardware und mit einer höheren Schicht 
des OS oder mit der Anwendung aber nicht mit einem anderen Treiber.

Kannst Du das mal erläutern?

Gruss
Treiber

Autor: Fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Also es ist so. Ich habe einen TDI Treiber der sich um Netzwerkpakete 
kümmert. Dieser soll bei bestimmten Paketen diese an ein weiteres 
Kernelmodul weitergeben welches die Pakete bearbeitet und teilweise 
wieder an den TD Treiber zum versenden übergibt! Daher müssen diese 
beiden Kernelmodule miteinander kommunizieren.

MFG Fresh

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind das dann nicht geschichtete (layered) Treiber?

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Man könnte es layered driver nennen. Es ist ein TDI Driver für eine NIC 
welcher mit einen Kernel Modul kommunizeren soll! Diese Kernel Modul 
soll jedoch von mehreren Treibern daten bekommen und an diese 
Weiteschicken! Wenn jedes Kernel Modul und jeder Treiber eine IRP hat 
sollte dies doch funktionieren oder?

MFG Fresh

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der saubere Weg geht über DeviceIoControl

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manomann, soviel geballtes Halbwissen auf einem Haufen...


>Häh? Wieso zwei sollen denn zwei Treiber miteinander kommunizieren?
Meinst du etwa, dass so komplexe Funktionalitäten und Abstraktionen wie
bspw. bei Audio, Netzwerk, USB uvm. in jew. einem Monoliten 
zusammenkompiliert sind?

>Der saubere Weg geht über DeviceIoControl
Das ist viel zu allgemein formuliert und hilft dem Thread-Starter nicht, 
denn DeviceIoControls sind IRPs eines bestimmten Typs, die jedoch nicht
in jedem Fall zur Anwendung kommen...


Wenn du TDI machen möchtest, kannst du im DDK ganz gut nachlesen, wies 
geht. Dort gibts auch Beispiele, wie man sich in den Stack (also die 
Layer) einklinken kann.

Kannst im Netz auch nach folgenden Schlüsselworten suchen, die liefern 
die ein paar Beispiele:

eine einfache UDP Verbindung kannste mit
ZwCreateFile auf L"\\Device\\Udp"
öffnen.

Referenz auf Device-Objekt:
ObReferenceObjectByHandle

zum Senden:
TDI_SEND_DATAGRAM

zum Datenempfang per UDP/TCP
TDI_SET_EVENT_HANDLER
TDI_EVENT_RECEIVE_DATAGRAM

zur Kommunikation zw. Treibern allg:
ZWCreateFile, dann IRP bauen und IoCallDriver aufrufen

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Danke erstmals für die Antworten.

Ich habe schon eine TDI Modul welches mir UDP emofäng und auch versenden 
kann. Wollte in diesen Driver in der DriverEntry Funktion den Befehl 
IoCreateDevice ausführen um irps auf diesen Treiber setzen zu können. 
Leider fehlt mir allerdings das DriverObject welches normallerweise von 
der DriverEntry Funktion übergeben wird! Liegt das daran das sich der 
Treiber nicht auf eine NIC sondern auf einen Port bindet?

Wie kann ich das sonst lösen oder ist das der falsche Ansatz? Werde mir 
auch die einzelnene von euch angeführten Funktionen ansehen!

MFG Fresh

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Habe bei der vorigen Nachricht vergessen dazuzuschreiben wie ich es 
implementieren will. Jeder Treiber bzw. jedes Kernel Modul ruft die 
Funktion IoCreateDevice auf um sich am I/O Manager anzumelden. Danach 
kann jeder Treiber bzw. jedes Kernel Modul mit einen anderen Treiber 
bzw. Kernel Modul über IRPs kommunizieren! Dieser Ansatz sollte doch 
funktionieren oder liege ich da falsch?

So sollte es doch möglich sein das mein TDI Treiber meinen Kernelmodul 
mitteilt das Daten angekommen sind und diese weiterleitet oder?

MFG Fresh

Autor: Alleskönner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
steht doch da:

ZwCreateFile
ObReferenceObjectByHandle

DDK lesen bildet...

Autor: Fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Habe schon das Internet durchforstet und die MSDN aber irgendwie finde 
ich nirgends eine Link zu einer Anleitung welche Funktionen der Treiber 
nun enthalten muss. ich dachte das ich beim DriverObject nur die 
Majorfunktionen einstellen muss und danach mit einen anderen Treiber auf 
diese einen IRP machen kann und das ich dazu im zweiten Treiber nur die 
Funktion IoGetDeviceObjectPointer benötige aber so geht es anscheinend 
nicht.

Ich habe aber nirgends etwas von zwCreateFile gelesen. Hat vielleicht 
irgendwer eine guten Link oder eine Beschreibung dazu?

DANKE

MFG Fresh

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du hier schon nachgesehen: http://www.osronline.com/ddkx/ddk.htm ?

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Habe die Kommunikation zwischen 2 KErnel Modulen hinbekommen. Ich 
schicke von Modul A nach Modul B einen write Request und Modul B geht in 
die Majorfunktion für wirte Requests. Dort wird derzeit nur eine Meldung
ausgegeben und die IoCompleteRequest(Irp, IO_NO_INCREMENT) ausgeführt. 
Leider funktioniert dies nur beim ersten mal danach kann ich Modul B 
nicht mehr beenden! In Modul A wird auch der IRP mit der Free Funktion 
wieder freigegeben.

Weis jemand woran das liegen kann?

MFG fresh

Autor: Leser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Heinz

>>Häh? Wieso zwei sollen denn zwei Treiber miteinander kommunizieren?
>Meinst du etwa, dass so komplexe Funktionalitäten und Abstraktionen wie
>bspw. bei Audio, Netzwerk, USB uvm. in jew. einem Monoliten
>zusammenkompiliert sind?

Nein, das habe ich auch nicht geschrieben. Ich habe bisjetzt garkeine 
Meinung geäussert sondern eine Frage gestellt.
Ich habe nur gefragt: "Häh? Wieso zwei sollen denn zwei Treiber 
miteinander kommunizieren?"

Alles was ich als Antworten sehe sind: Layer, nicht verschiedene 
Treiber.
Das ist sicherlich ein Definitionsproblem, aber IMHO kommunizieren nicht 
Treiber miteinander, sondern eine Applikation benutzt Treiber.
Oder sind hier die beiden Treiber in jeweils einem von zwei 
verschiedenen Rechnern gemeint?

Gruss
Leser

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fresh wrote:
> Hallo
>
> Habe die Kommunikation zwischen 2 KErnel Modulen hinbekommen. Ich
> schicke von Modul A nach Modul B einen write Request und Modul B geht in
> die Majorfunktion für wirte Requests.

Und wenn du jetzt statt des wirte ein IOCTL nimmst, dann bist du auf dem 
richtigen Weg.

Für das Handling der IRPs suchst du dir am besten Treiberbeispiele aus 
dem DDK (heißt jetzt WDK) - das Standardbeispiel dort ist der Toaster, 
der enthält so ziemlich alle Konstellationen.

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Wenn ich nun das write in IOCTL ändere muss ich im Modul welches den IRP 
Empfängt mittels einer Case

anweisung herausfinden was zu tun ist also entweder schreiben oder 
lesen!? weil das IOCTL gibts ja gar

nicht laut msdn. Es gibt als Vergleich Device_control. es muss doch mit 
den Write auch gehen oder? Das wird ja nicht der Grund sein warum mein 
empfangentes Modul sich nicht mehr beenden lässt oder?

MFG fresh

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fresh wrote:
> nicht laut msdn. Es gibt als Vergleich Device_control.

Das meine ich. Genau IRP_MJ_DEVICE_CONTROL

> es muss doch mit den Write auch gehen oder?

Da wäre ich sehr vorsichtig, denn Windows ist nicht Open Source und man 
kann nicht einfach nachsehen, was los ist, wenn es irgendwo klemmt - und 
das tut es erfahrungsgemäß gerne.

MSD ist als Quelle zum Treiberschreiben nicht ausreichend. Hast du mal 
auf dem OSR-Link nachgelesen, das ich oben angegeben hatte?

Das hier scheint auch ganz interessant zu sein: 
http://www.acc.umu.se/~bosse/

Wenn du dort in FileDisk nachsiehst, findest du die Behandlung von 
IRP_MJ_DEVICE_CONTROL. Mach es so, wie die MS-Fuzzies das auch machen, 
dann bist du zwar nicht unbedingt auf der sicheren Seite, aber zumindest 
nich sehr weit davon.

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Leser
>IMHO kommunizieren nicht Treiber miteinander
deine HO ist für mich und den Rest der Welt total egal...

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heinz wrote:
> deine HO ist für mich und den Rest der Welt total egal...

Deine auch.

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Uhu

>Deine auch.

bleib du mal bei deiner "Sicherheitseinrichtung" die 200mA Pulse
von der Phase zum Schutzleiter schickt...

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Also wie bereits ober geschrieben funktioniert die Kommunikation meiner 
beiden Driver mittlerweile. Leider nur beim ersten mal. Wenn ich danach 
deiden Driver beenden will lässt sich der TDI Treiber (IRP Empfänger) 
nicht beenden. Er sagt immer das sich in seinen Zustand nicht beenden 
lässt! Woran kann das liegen??

Im driver der den IRP sendet gebe ich diesen auch weider Frei und im 
empfänger habe ich auch den Befehl zum zurückgeben an den IO Controller 
drin!

MFG fresh

Autor: SiO2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum sollten Treiber nicht miteinander Kommunizieren können? Unter 
Linux sollte es einfach sein. Funktion in Treiber A exportieren, genauso 
in Treiber B und schon kann auf den anderen Treiber auf diese Funktionen 
zugegriffen werden, nur muss man sicherstellen, daß der andre Treiber 
auch wirklich schon läuft.

Autor: Codeguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Unter Linux sollte es einfach sein.
Frage lesen
Frage verstehen
überlegen ob Antwort möglich und ggf. antworten

Wer will wissen, wies unter Linux läuft? - Niemand!
War dein Beitrag hilfreich - Neeein!

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Habe mir nun überlegt die Kommunikation mit der NIC über TDI nicht in 
einen eigenene Treiber zu geben sondern meine Funktion in eine WDM 
Treiber zu geben und dort auch auf das TDI Interface zuzugreifen damit 
erspart ich mir die Performance für dir IRPs.

Ist dies Möglich das ich in eine normalen WDM Treiber der selber keine 
HArdware steuert auf das TDI Interface zugreife?

MFG Fresh

Autor: Blödmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin gespannt, wie du den TDI Treiber benutzen willst, ohne IRPs zu 
verwenden...

Autor: Fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich schreibe gerade die all in one Version des Treiber also TDI und 
normale Logik alles in eine Treiber! Er funktioniert derzeit soweit 
recht gut nut habe ich ein ´komisches Phänomen drin! Er macht immer die 
selbe Arbeit nur teilweise braucht er 50% eines Core2Duos und teilweise 
0%. Das Schwanken kommt immer Blockweise also mal ne minute 50% und dann 
mal ne minute 0% usw. Aber leider ändert es sich nicht so regelmässig!

Hat jemand eine Idee was es sein könnte?

DANKE

MFG Fresh

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fresh wrote:
> Hat jemand eine Idee was es sein könnte?

Erwartest du darauf ensthaft eine Antwort?

Autor: Steven H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hat jemand eine Idee was es sein könnte?

Hier handelt es sich zweifellos um eine Verzerrung im 
Raum-Zeit-Kontinuum, vermutlich hervorgerufen durch die nahe Geburt 
eines schwarzen Lochs.

Stell den Rechner mal in einen anderen Raum, oder lege dein 
Arbeitszimmer mit Bleiplatten aus, dann müßte es gehen.

Falls das nicht hilft, wiege mal bitte deinen Computer und schreib mal 
wie schwer er bei 0% und bei 50% Rechenlast jeweils ist. Das würde bei 
der Fehlersuche helfen, falls ich mich mit der Verzerrungs-Theorie doch 
irren sollte...

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Habe ein kleines Problem mit meinen Treiber. Er stürzt jedesmal beim 
entladen ab! Kann das daran liegen, das ich eine globle Variable habe 
auf die zwei Funktionen schreiben und lesen die in einen 
unterschiedlichen Dispatch level arbeiten?

DANKE

MFG fresh

Autor: T:Stütz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@fresh

Niemals globale Variablen verwenden, solche Dinge gehören gefälligst in 
die
Device-Extension die du ja beim Erzeugen des Gerätes angelegt hast.

Damit ist sichergestellt das wenn dein Treiber läuft du auch Zugriff 
darauf hast.

Außerdem Zugriffe auf "globale" Variablen die also von mehreren Stellen 
schreibend/lesend zugegriffen werden kann immer gegeneinander sperren 
(Stichwort SpinLock)

mfg
T.Stütz

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Danke für deine schnelle Antwort! Ich habe es nämlich so das meine UDP 
Empfangsfunktion die empfangenen Daten in einen Buffers schreiben soll 
und gleichzeitig daten aus einen anderen Buffer schicken soll! Dachte 
daher das ich einfach zwei globale Variablen mache die die zwei buffer 
darstellen.

Das heist also ich muss dies in diese driver extension einbauen?

MFG fresh

Autor: T:Stütz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@fresh

Ich spreche von DeviceObject->DeviceExtension (Typ DEVICE_EXTENSION)
Das DeviceObject hast du ja vorher per IoCreateDevice() erzeugt, dazu 
hast du als Parameter das DriverObject übergeben.

Eine "DriverExtension" gibt es meines Wissens nicht.

Also: es gibt EIN DriverObject (repräsentiert quasi den Treiber)
diesem DriverObject können mehrere DeviceObjects zugeordnet sein 
(jeweils per IoCreateDevice() erzeugt) dies sind also die Geräte die von 
diesem Treiber bedient werden (bei dir wären das mehrere Netzwerkkarten 
die alle von einem Treiber bedient werden).Jedes diese DeviceObjects 
kann zusätzliche Daten enthalten das ist dann die DeviceExtension (bei 
dir wäre das z.B. die der Netzwerkkarte zugeordnete 
IP-Adresse/MACAdresse)

Du willst quasi zwei Puffer für Send/Empfang pro Netzwerkkarte haben =>
beide Puffer in die Device-Extension oder
in der Device-Extension Zeiger definieren, die einen auf einen 
Speicherbereich der per ExAllocatePool Speicher angefordert (NonPaged!) 
wurde (NULL-Zeiger überwachen!!)

Ich hoffe das macht es etwas klarer.

mfG
T.Stütz

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Habe das mit den Buffern jetzt so gelöst und es funktioniert echt gut! 
Einzig stört mich ein wenig das ich bei 8000 eingehenden und 8000 
ausgehenden Paketen mit jeweils 554Byte bereits eine CPU Last von fast 
20% habe bei einen Core 2 Duo mit 2,2Ghz oder ist das fast normal! Die 
Pakete werden eigentlich nicht bearbeitet sonder derzeit nur die 
Addressen geändert und weitergeschickt!

MFG Fresh

Autor: Alter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann sammle doch bis du eine größere Menge zusammen hast und versende 
die auf einmal zu dem anderen Treiber. Ein Timeout könnte dafür sorgen, 
dass die Daten auch rausgehen, wenn nicht die Maximalmenge innerhalb 
einer Zeitscheibe zusammenkommt, so bleibt nix hängen, sondern wird 
höchstens kurz verzögert.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich beschäftige mich noch immer mit den Thema Treiberentwicklung und 
habe daher wieder eine Frage. Ich will das ein Thread so lange wartet 
bis ihn ein zweiter aufweckt! Habe ein Beispiel gefunden mit einen 
Semaphore das bei einen Wait aufruf decrementiert wird und bei eine 
Signal aufruf incrementiert! Ist das gane damit machbar!?

DANKE

MFG Gast

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe davor vergessen zu erwähnen das der Thread alle 2ms aufgeweckt 
wird!

MFG Gast

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, so mancht man das. Die 2 ms sollten kein Problem sein, wenn die 
Prozessorlast durch den Thread gering genug ist.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Habe nun ein Semaphore eingebaut und der thread wird auch perfekt 
aufgeweckt verrichtet seine arbeit und geht wieder in den wait state. 
Nur stürzt er immer ab wenn ich den Treiber entlade! habe mit softice 
festgestellt das er entweder beim signal oder im wait abstürzt und das 
obwohl noch nicht einmal die erste Zeile der Unloadfunktion aufgerufen 
wurde! Hat jemand vielleicht eine Tipp?

MFG Gast

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Semaphore-Handle ist im Kernelmode ein Zeiger auf eine 
Datenstruktur.

Wenn die Datenstruktur nicht mehr existiert und das Handle benutzt wird, 
krachts.

Du mußt also dafür sorgen, daß alles sauber abgebaut wird, wenn du den 
Treiber entlädtst.

Autor: Alter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Uhu
irgendwie werd ich das Gefühl nicht los, dass du so gar keine Ahnung 
hast und daher immer unkonkretes Zeug schreibst...


Hier mal was konkretes...
...Ist zwar ein Event, aber das Prinzip ist bei der Semaphore das 
gleiche, wenns ums Beenden geht:

Thread:

while (1)
{
   KeWaitForSingleObject(&m_evWait, Executive, KernelMode, FALSE, NULL);
   if ( m_WorkerRun == false )
   {
  DPF(D_TERSE, ("StreamerThread: terminating"));
  return;
   }
   //...
}


Beenden geht so:
m_WorkerRun = false;
KeSetEvent(&m_evWait, 0, FALSE);
ZwClose(m_hWorkerThread);

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Also im Prinzip mach iches eh so! ich habe eine funktion die immer bei 
einen empfang einer UDP nachricht aufgerufen wird. diese Funktion gibt 
ein signal an das semaphor und startet dadruch einen thread der vorher 
auf das semaphor gewartet hat. Wenn ich nun den treiber entlade setzte 
ich eine globale variable auf 0 damit der udp teil nicht weiter macht. 
danach starte ich ein signal auf das semaphor damit der thread nochmals 
gestartet wird. im threat fragt er die globale variable ab und 
terminiert sich selber!

Leider bekomme ich immer einen Page Fault (0Eh) Fehler!

Weis jemand woran das liegen kann?

MFG Gast

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Habe jetzt statt einen semaphor ein Event genommen und es arbeitet echt 
super. Ausser das entladen des Treiber funktioniert nicht immer 
gelegentlich bekomme ich einen "Page Fault (9Eh)" Fehler. Wenn ich mir 
dann denn stack ansehe pasiert der Fehler meistens im wait des threads!

Das entladen mache ich wie um vorigen post beschrieben!

MFG Gast

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Habe noch eine Frage zur Treiberkommunikation! Ich habe ein Usermode 
Program welches Mittels DeviceioControl und CreateFile auf einen Treiber 
zugreift! Nun muss ich diesen Zugriff aus einen Treiber aus machen wobei 
der Createfile Befehl nicht geht!

Benutze derzeit den Befehl IoGetDeviceObjectPointer zum aufbauen der 
Verbindung. Kann ich damit die selben Befehle wie mit DeviceIOControl 
übergeben!?

MFG Gast

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IRP_MJ_INTERNAL_DEVICE_CONTROL ist die Version von 
IRP_MJ_DEVICE_CONTROL, die zur Kommunikation zwischen Treibern benutzt 
wird.

http://msdn.microsoft.com/en-us/library/ms806159.aspx

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Habe die Kommunikatin zum anderen Treiber erfolgreich implementieren 
können! Jetzt muss ich auch eine Funktion implementieren die an den 
anderen treiber einen irp schickt und daten zurück bekommt. Übergebe 
daher auch eine OutputBufferLength. Meine Frage ist nun wann ich die 
Daten abrufen kann und wie?! Bekomme ich die Daten sofort nach den 
IoCallDriver aufruf oder in der completionroutine? Und wo sind die Daten 
dann im IRP zu finden!

Danke im vorhinein für die Antworten!

MFG Gast

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich in der Completionroutine. Mit dem I/O-complete signalisiert 
der Zieltreiber, daß der IRP fertig bearbeitet ist, also z.B. Daten in 
einen Puffer geschrieben wurden - oder daß irgenwas schief ging.

> Und wo sind die Daten dann im IRP zu finden!

Üblicherweise im Puffer, der übergeben wurde. Man kann aber natürlich 
auch einen gemeinsamen Speicherbereich benutzen - im Kernelmode hat man 
alle Freiheiten... Nur obs auch archtektonisch und sicherheitstechnisch 
gut ist, steht auf einem anderen Blatt.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Habe folgenden IRP Code:
irpStack = IoGetNextIrpStackLocation(irp);
        irpStack->MajorFunction = IRP_MJ_DEVICE_CONTROL;
        irpStack->MinorFunction = 0;
        irpStack->Parameters.DeviceIoControl.IoControlCode = IOCTL_DRIVER_OUT;
        irpStack->Parameters.DeviceIoControl.OutputBufferLength  = sizeof(IOCTL_RX_OUT);
      irpStack->Parameters.DeviceIoControl.InputBufferLength  = sizeof(IOCTL_RX_IN);

Nun würde ich gerne in der completion funktion die Daten aus den 
IOCTL_RX_OUT auslesen die mir der ander Treiber gegeben hat!

Mein Versuch:
IOCTL_RX_OUT data_tmp;

data_tmp = (IOCTL_RX_OUT*)(irp->AssociatedIrp.SystemBuffer);

Ist diese Vorgangsweise richtig!?

DANKE

MFG Gast

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Also die Kommunikation zwischen den Treibern geht! Aber leider habe ich 
oft einen Blue Screen wegen den IRQL. vorallem bei den memcpy befehlen! 
Habe auch schon RtlCopyMemory versucht was aber auch Fehler mit den IRQL 
bringt!

Hat jemand einen vielleicht einen Tip oder sind memcpy Befehle im Kernel 
allgemein ein Problem?

MFG Gast

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das deutet darauf hin, daß die Kopierroutine in einem Kontext gerufen 
wird, der keine Zugriffsrechte auf die Daten hat.

Treiber laufen auf IRQL 0, während Anwenderprozesse auf IRQL 3 laufen.

Die Kopierroutinen selbst laufen sehr zuverlässig - sind ja auch gut 
getestet...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI

Also mein memcpy Befehl arbeitet in einen Thread der zu einer Klasse 
gehört. Dieser Thread alloziiert sich selber speicher und in diesen 
Speicher will er einen Speicher welcher ebenfalls zur selben Klassse 
gehört kopieren.

Kann das dann ein Problem mit den Kontext sein!?

MFG Gast

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja. Z.B. wenn der Thread durch ein Event zum Leben erwacht.

Systemthreads sind nicht an einen Prozeßkontext gebunden. Wenn ein Th. 
im falschen Kontext aufwacht, dann darf er nur das, was in diesem 
Kontext möglich ist.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Habe das Problem mit den memcpy lösen können hätte jetzt aber noch ne 
Frage zu den IRPs. Ich mache immer wenn ich Daten zum oder vom anderen 
Treiber schicken will ein neues IRP mit IoAllocateIrp. Nun ist mir 
aufgefallen das mein System Cache rasant ansteigt und ich vermute das 
der Rechner deswegen nach einer Zeit nicht mehr reagiert! ISt das 
Möglich?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.