Driver IO Communication

[nirajembedded]

Hi,
Target OS : Windows XP
I am developing a simple driver which will communicate to ISA based
card.
An application written in VB .net will communicate to it.
I have seen certain machanism to communicate to any device driver
one of them is using IOCTL.
My VB.net application hava timer running after every 200 ms or may
be less than that. and polls for the data to come from driver. I feel
that IOCTL communication for this may create some performence issue due
to memory exchanged for every input/output and time taken for it's
processing.
Can anybody shade some light on it and suggest me some better
machanism to implement this ?

Regards

 

[Don Burn]

Well the first question is how much data are you transferring, if it is just
a little this is terrible, but you are doing a lot of system calls. A
better way of doing this is have the driver pend the IRP until there is new
data, and the application issues either an OVERLAPPED I/O or has the read
done in a thread that can wait.

 

[nirajembedded]

Thanks a lot...
Following your suggestion I have stiudied on IPR and OVERLAPPED I/O.
I have found that these mechanisms are used for communication bet'n
either two applications or bet'n two drivers. My next problem is how
far it is feasible and advisable to use it for application and driver
communication as both are running different process areas with
different restrictions type (i.e. on is running in kernel space while
other in User space..).
Hope I am not making any child like mistake...
thanks again,
Niraj

 

[Don Burn]

Well most drivers use this mechanism. Yes people have implemented more
complex mechanisms with shared memory, and multiple events, etc. The ironic
thing is for low to medium bandwidth applications, which yours sounds like,
the complex mechanisms do nothing but take a lot more code.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

 

[nirajembedded]

Thanks again,
Let me be more relevant to my application and it's usage. I need a
machanism through which my driver continuesly sends the data to my
application. Here in all the suggested mode it is an application which
either use Readfile or DeviceIOControl to request and wait for
response and that need to be in loop continuesly.
My question is can I set any application functions in the driver so
that when ever event occurs it calls it back and application get
notify.

Regards,
Niraj

 

[Don Burn]

This is the inverted call model. You do OVERLAPPED I/O and your application
issues one or more I/O's with an event specified for each. Then when the
driver has something to communicate to the application, it completes the IRP
which will cause the OS to signal the event and return the data to the
application. The application processes the data and reissues the I/O call
to send the request back to the driver for the next time.

 

[nirajembedded]

Hi,
Can I use named Pipe between driver and application instead of IRP ?
Niraj

 

[Don Burn]

Using a pipe is completely undocumented and will likely not pass WHQL
testing if you need it. Driver in Windows are designed to work on IRP's,
this is a very basic operation, using something other than an IRP is just
going to cause you problems in the end.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

 

[Doron Holan [MS]]

even if you got a named pipe to work, the underlying transport for the pipe
is a PIRP

d