Prev: Synchronization on multiple USB read/writes
Next: about function COM_IOControl in Virtual COM driver
From: chris.aseltine on 26 Apr 2008 15:05
On Apr 26, 1:35 pm, madhukar.gu...(a)gmail.com wrote:

> One other thing i forgot to mention is that if i register preprocessor
> routine IRP_MJ_READ instead of EvtIoRead then i wont be able to use
> the queues. This would change the entire design of my driver.

Sucks, doesn't it? Welcome to the club.

You don't have to totally get rid of your I/O queues. You can still
use them as cancel-safe containers for pended I/O.

However, you'll still need to do several checks in your IRP preprocess
routine to check if you can complete an incoming read synchronously,
or pass it off to your queues (and thus EvtIoRead).

Also, you mentioned something about XP versus Vista -- again, the bug
is in MSComm32.ocx, not the operating system, so that isn't a factor
here.
From: madhukar.gubba on 28 Apr 2008 08:16
If the bug is in MSComm32.ocx the why not the MS folks fix it. I have
seen this problem is being asked in many places in other forums as
well. An alternative could be the possible fix in serial sample as
well.

My driver already passed DTM and other stress tests. If i had to make
any changes i need to repeat all the test procedures again.

One more question.

If i register IRP preprocess routine, when the callback function is
triggered i have support routines (Like SerialStartOrQueue(),
SerialStartRead() routines) using WDFREQUEST object instead of IRP .
Do i need to change all the WDFREQUEST objects to get the IRP pointer?
or is there any other way to do it?

Thank You.

Regards,
Madhukar
From: chris.aseltine on 28 Apr 2008 11:55
On Apr 28, 7:16 am, madhukar.gu...(a)gmail.com wrote:

> If the bug is in MSComm32.ocx the why not the MS folks fix it.

Probably because they don't care?

> I have seen this problem is being asked in many places in other
> forums as well. An alternative could be the possible fix in serial
> sample as well.

Again, don't see why you're proposing to "fix" anything in the drivers
when the bug is with the OCX control.

> My driver already passed DTM and other stress tests. If i had to make
> any changes i need to repeat all the test procedures again.

Woe is you, it seems.

> If i register IRP preprocess routine, when the callback function is
> triggered i have support routines (Like SerialStartOrQueue(),
> SerialStartRead() routines) using WDFREQUEST object instead of IRP .
> Do i need to change all the WDFREQUEST objects to get the IRP pointer?
> or is there any other way to do it?

I already explained this in my prior post. Decide in your WDM
preprocess routine if you're going to complete the IRP synchronously
or not. If you're not, just pass it to your I/O queue, and your other
routines can stay the way they are.
First  |  Prev  | 
Pages: 1 2
Prev: Synchronization on multiple USB read/writes
Next: about function COM_IOControl in Virtual COM driver