[C++ / Drivers] Communicatie tussen App & Driver

[superboer]

Wij zijn druk bezig met het ontwikkelen van een intermediate
NIC-driver voor win2000 (WDM-driver) en wij vroegen ons af
of het mogelijk (en zo ja ! Hoe ?) is om data die de driver
ontvangt vanuit NDIS door te sluizen naar onze applicatie
die daar dan een kleine bewerking op uitvoert.

Wij hebben wel al een mogelijke oplossing via Readfile, maar
vinden dit geen goede oplossing, omdat dit dan vanuit de
applicatie gaat en wij zijn nieuwsgierig naar een oplossing
waarbij de driver een interrrupt(of callback) ofzoiets
genereerd zodat de applicatie dan weet van : "Goh er is data !"

[Verwijderd]

Driver writing is niet helemaal mijn ding, maar wil je dit wel? dan zou je driver afhankelijk worden of je (usermode) applicatie draait en daarbij haal je je ook nog es allerlei nare user/kernelmode synchronisation problemen in je nek. idee/gokje: Je zou je app evt met een WaitForMultipleObjects kunnen laten wachten op een event wat je vanuit je driver met KeSetEvent afschiet (en dan alsnog met readfile je data naar usermode sleuren)?

[superboer]

Op dinsdag 14 mei 2002 12:57 schreef Yarvieh het volgende:
Driver writing is niet helemaal mijn ding, maar wil je dit wel? dan zou je driver afhankelijk worden of je (usermode) applicatie draait en daarbij haal je je ook nog es allerlei nare user/kernelmode synchronisation problemen in je nek. ......

Ja, dat wil ik

[farlane]

Het is mogelijk om kernel mode drivers memory te laten sharen met user mode apps.

Zie http://support.microsoft.com/default.aspx?scid=kb;EN-US;q191840

Je zou ook de standaard IRP_MJ_READ kunnen afvangen, die normaal bij een ReadFile wordt aangeroepen. Aangezien dit ook Overlapped mogelijk is, is het niet een slechte methode.

Verder is er ook nog de mogelijkheid om te werken met de DeviceIOCtls, maar dat zou betekenen dat je user mode app de driver moet pollen, wat iha niet ten goede komt aan de prestaties.

btw, Voordat je hiermee aan de slag gaat, is het verstandig om een boek te kopen, ( bijvoorbeeld Programming the WDM van Walter Oney ) want met alleen de DDK docs heb je heel ploeteren voor de boeg. ( Ook met dat boek trouwens )

[superboer]

Op dinsdag 14 mei 2002 13:40 schreef farlane het volgende:
Het is mogelijk om kernel mode drivers memory te laten sharen met user mode apps.

Zie http://support.microsoft.com/default.aspx?scid=kb;EN-US;q191840

Je zou ook de standaard IRP_MJ_READ kunnen afvangen, die normaal bij een ReadFile wordt aangeroepen. Aangezien dit ook Overlapped mogelijk is, is het niet een slechte methode.

Verder is er ook nog de mogelijkheid om te werken met de DeviceIOCtls, maar dat zou betekenen dat je user mode app de driver moet pollen, wat iha niet ten goede komt aan de prestaties.

btw, Voordat je hiermee aan de slag gaat, is het verstandig om een boek te kopen, ( bijvoorbeeld Programming the WDM van Walter Oney ) want met alleen de DDK docs heb je heel ploeteren voor de boeg. ( Ook met dat boek trouwens )

Opmerkingen :

1. Wij wilden idd proberen om geen gebruik te maken van
pollen.

2. Wij hebben een paar boeken tot onze beschikking waaronder
die van Walter Oney, maar in die boeken staan nergens
echt duidelijk hoe je vanuit de driver communiceert met
een applicatie (anders dan met ReadFile)

3. Wij waren idd ook op die mogelijkheid gekomen om
IRP_MJ_READ af te vangen, maar omdat hierbij het
initiatief weer vanuit de applicatie komt, waren wij
benieuwd naar een andere mogelijkheid waarbij echt
de driver het initiatief neemt !

[Verwijderd]

Op dinsdag 14 mei 2002 12:45 schreef superboer het volgende:
wij zijn nieuwsgierig naar een oplossing
waarbij de driver een interrrupt(of callback) ofzoiets
genereerd zodat de applicatie dan weet van : "Goh er is data !"

Dit kan ongetwijfeld (alles kan) maar ik zou niet weten hoe en daarnaast is het compleet ongewenst. Gewoon een extra thread in de applicatie die een continue blocking read(), poll() of synchronisatie ioctl() op de driver uitvoert is een veelgebruikte oplossing voor dit soort problemen en is ook de standaard manier om dit soort problemen aan te pakken.

Een kernel die actief met een (misschien niet runnende) applicatie communiceert is een gigantische designfout.

[farlane]

3. Wij waren idd ook op die mogelijkheid gekomen om
IRP_MJ_READ af te vangen, maar omdat hierbij het
initiatief weer vanuit de applicatie komt, waren wij
benieuwd naar een andere mogelijkheid waarbij echt
de driver het initiatief neemt !

Zoals gezegd, als je deze overlapped toepast, is het geen verkeerde manier van werken.

Beelzebubu gaf ook al aan dat drivers die zelf het initiatief nemen om 'naar boven' te communiceren niet echt een geweldig goed ontwerp hebben.