UMDF and completion routines

NTDEV
1

I have a small design problem with my UMDF driver and I’d like to hear
your opinions. I need to implement an equivallent of IRP completion
routines. There is IRequestCallbackRequestCompletion interface for this
purpose. The question is how and where to implement it when I need two
(or more) different completion routines. UMDF samples are too simple;
they implement just one so IRequestCallbackRequestCompletion is
implemented by device object class. I see following possibilities:

  • implement generic OnCompletion() routine by device object class and
    make the decision inside based on pContext parameter and call the
    appropriate completion routine.

  • create separate one purpose callback classes for every completion
    routine which’d implement just this interface and create one instance of
    every class per device object.

The next solution could be a queue but I don’t need it. Requests are
queued elsewhere (outside of framework) and everything what I need is to
send them to default IO target and do something with context in
completion routine.

(oh well, WDM is simpler in some cases…)

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

2

Yeah - completion routine handling in UMDF is painful when you need more than one. Sorry about that.

I think your first suggestion is the simplest … one completion routine with a switch to figure out the right underlying function to invoke.

If you’re using ATL then implementing a simple delegate class isn’t that hard but otherwise it’s one more QueryInterface to write and that’s a royal pain.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, February 05, 2009 3:34 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] UMDF and completion routines

I have a small design problem with my UMDF driver and I’d like to hear
your opinions. I need to implement an equivallent of IRP completion
routines. There is IRequestCallbackRequestCompletion interface for this
purpose. The question is how and where to implement it when I need two
(or more) different completion routines. UMDF samples are too simple;
they implement just one so IRequestCallbackRequestCompletion is
implemented by device object class. I see following possibilities:

  • implement generic OnCompletion() routine by device object class and
    make the decision inside based on pContext parameter and call the
    appropriate completion routine.

  • create separate one purpose callback classes for every completion
    routine which’d implement just this interface and create one instance of
    every class per device object.

The next solution could be a queue but I don’t need it. Requests are
queued elsewhere (outside of framework) and everything what I need is to
send them to default IO target and do something with context in
completion routine.

(oh well, WDM is simpler in some cases…)

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Distinguishing based on the context avoids the need for additional objects but depending upon how hard it is to make the distinction, may affect complexity/readability and (probably to a smaller extent) perf. After making the distinction, you can call separately implemented helpers which will give you the same effect of having different completion routines.

Separate classes may be cleaner if distinction is not straightforward, and if the devices are not expected to be too many (so that the memory overhead of the additional objects is very small).

Praveen

4

Thanks. I use ATL so I prefer a bit more the second solution. The first
one is a bit more complex in this particular case because I already have
contexts from outside (library) so I’d need to create something to
handle them.

I was under impression I’m overlooking something simple :slight_smile: Well, it
could be a good idea to use more completion routines in some sample just
to show a standard pattern if you have some.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, February 06, 2009 12:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF and completion routines

Yeah - completion routine handling in UMDF is painful when
you need more than one. Sorry about that.

I think your first suggestion is the simplest … one
completion routine with a switch to figure out the right
underlying function to invoke.

If you’re using ATL then implementing a simple delegate class
isn’t that hard but otherwise it’s one more QueryInterface to
write and that’s a royal pain.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, February 05, 2009 3:34 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] UMDF and completion routines

I have a small design problem with my UMDF driver and I’d like to hear
your opinions. I need to implement an equivallent of IRP completion
routines. There is IRequestCallbackRequestCompletion
interface for this
purpose. The question is how and where to implement it when I need two
(or more) different completion routines. UMDF samples are too simple;
they implement just one so IRequestCallbackRequestCompletion is
implemented by device object class. I see following possibilities:

  • implement generic OnCompletion() routine by device object class and
    make the decision inside based on pContext parameter and call the
    appropriate completion routine.

  • create separate one purpose callback classes for every completion
    routine which’d implement just this interface and create one
    instance of
    every class per device object.

The next solution could be a queue but I don’t need it. Requests are
queued elsewhere (outside of framework) and everything what I
need is to
send them to default IO target and do something with context in
completion routine.

(oh well, WDM is simpler in some cases…)

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

5

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Rao
Sent: Friday, February 06, 2009 12:58 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF and completion routines

Distinguishing based on the context avoids the need for
additional objects but depending upon how hard it is to make
the distinction, may affect complexity/readability and
(probably to a smaller extent) perf. After making the
distinction, you can call separately implemented helpers
which will give you the same effect of having different
completion routines.

This is exactly how I mentioned it :slight_smile:

Separate classes may be cleaner if distinction is not
straightforward, and if the devices are not expected to be
too many (so that the memory overhead of the additional
objects is very small).

For this particular case it seems as better solution.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]