KMDF object oddities

NTDEV
1

I’ve run into the following issues with Kmdf which surprised me. Some may
be bugs, some may be design decisions. All can obviously be worked around.
Unless I missed it, none are documented.

  1. In EvtCleanupCallback for a WDFWORKITEM, WdfWorkItemGetParentObject
    returns NULL.

  2. Why do we have WdfWorkItemGetParentObject at all? It seems a general
    WdfObjectGetParentObject would be useful.

  3. By the time EvtCleanupCallback is invoked for a WDFQUEUE object, it
    appears that any requests on the queue have been canceled (without invoking
    EvtIoCanceledOnQueue). If the framework were to wait until after calling
    cleanup to purge the queue, that would allow the caller to drain the queue
    as he sees fit.

  4. When an object that has child objects is deleted, the order of callbacks
    is Cleanup Children, Cleanup Parent, Destroy Children, Destroy Parent. I
    would prefer to see: Cleanup Parent, Cleanup Children, Destroy Children,
    Destroy Parent. This would give the opportunity to do global cleanup that
    requires the full existence of the child objects in the cleanup for the
    parent.

  • Dan.
2

  1. I’ll look into it. I never liked this api and I also don’t see a
    use for it. IMO, it should have never been there

  2. Because there is no real need for it. You have to know the parent’s
    type, might as well store it in the child’s context

  3. by design. Cleanup() is called well after the queue has been
    purged. You have pnp callbacks that let you purge the queue as you see
    fit (SelfManagedIoCleanup for instance) or queue callbacks (EvtIoStop).
    The contract for cleanup is that there is nothing else acting on or in
    the queue so it is safe time to free things lock free

  4. completely by design. Sorry, not going to change. The point here is
    that each object in its cleanup routine synchronizes and finishes all of
    its activity. By doing this, when the parent runs it can clean up
    /destroy/release the child objects without having to worry about
    synchronizing with the child object’s activities. For instance, a
    WDFWORKITEM will no longer have the work item queued when its parent
    gets a cleanup. Also, only cleanup() has a guaranteed ordering,
    destroy() does not since dangling references can cause out of order
    destruction.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Tuesday, December 05, 2006 6:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF object oddities

I’ve run into the following issues with Kmdf which surprised me. Some
may
be bugs, some may be design decisions. All can obviously be worked
around.
Unless I missed it, none are documented.

  1. In EvtCleanupCallback for a WDFWORKITEM, WdfWorkItemGetParentObject
    returns NULL.

  2. Why do we have WdfWorkItemGetParentObject at all? It seems a general
    WdfObjectGetParentObject would be useful.

  3. By the time EvtCleanupCallback is invoked for a WDFQUEUE object, it
    appears that any requests on the queue have been canceled (without
    invoking
    EvtIoCanceledOnQueue). If the framework were to wait until after
    calling
    cleanup to purge the queue, that would allow the caller to drain the
    queue
    as he sees fit.

  4. When an object that has child objects is deleted, the order of
    callbacks
    is Cleanup Children, Cleanup Parent, Destroy Children, Destroy Parent.
    I
    would prefer to see: Cleanup Parent, Cleanup Children, Destroy Children,
    Destroy Parent. This would give the opportunity to do global cleanup
    that
    requires the full existence of the child objects in the cleanup for the
    parent.

  • Dan.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

One out of four ain’t bad :slight_smile:

Perhaps in some future version of Kmdf you could consider a third object
deletion callback, called before the framework has done anything to the
object (and called for the parent before the children).

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, December 05, 2006 8:32 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF object oddities

  1. I’ll look into it. I never liked this api and I also don’t see a use
    for it. IMO, it should have never been there

  2. Because there is no real need for it. You have to know the parent’s
    type, might as well store it in the child’s context

  3. by design. Cleanup() is called well after the queue has been purged.
    You have pnp callbacks that let you purge the queue as you see fit
    (SelfManagedIoCleanup for instance) or queue callbacks (EvtIoStop). The
    contract for cleanup is that there is nothing else acting on or in the queue
    so it is safe time to free things lock free

  4. completely by design. Sorry, not going to change. The point here is
    that each object in its cleanup routine synchronizes and finishes all of its
    activity. By doing this, when the parent runs it can clean up
    /destroy/release the child objects without having to worry about
    synchronizing with the child object’s activities. For instance, a
    WDFWORKITEM will no longer have the work item queued when its parent gets a
    cleanup. Also, only cleanup() has a guaranteed ordering,
    destroy() does not since dangling references can cause out of order
    destruction.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Tuesday, December 05, 2006 6:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF object oddities

I’ve run into the following issues with Kmdf which surprised me. Some may
be bugs, some may be design decisions. All can obviously be worked around.
Unless I missed it, none are documented.

  1. In EvtCleanupCallback for a WDFWORKITEM, WdfWorkItemGetParentObject
    returns NULL.

  2. Why do we have WdfWorkItemGetParentObject at all? It seems a general
    WdfObjectGetParentObject would be useful.

  3. By the time EvtCleanupCallback is invoked for a WDFQUEUE object, it
    appears that any requests on the queue have been canceled (without invoking
    EvtIoCanceledOnQueue). If the framework were to wait until after calling
    cleanup to purge the queue, that would allow the caller to drain the queue
    as he sees fit.

  4. When an object that has child objects is deleted, the order of callbacks
    is Cleanup Children, Cleanup Parent, Destroy Children, Destroy Parent. I
    would prefer to see: Cleanup Parent, Cleanup Children, Destroy Children,
    Destroy Parent. This would give the opportunity to do global cleanup that
    requires the full existence of the child objects in the cleanup for the
    parent.

  • Dan.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

4

I’m not sure I see the pattern’s applicability. You said you want to
delete some global resource, why can’t you delete the resource in the
parent’s cleanup routine after everyone is cleaned up and finished using
it?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Tuesday, December 05, 2006 8:11 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF object oddities

One out of four ain’t bad :slight_smile:

Perhaps in some future version of Kmdf you could consider a third object
deletion callback, called before the framework has done anything to the
object (and called for the parent before the children).

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, December 05, 2006 8:32 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF object oddities

  1. I’ll look into it. I never liked this api and I also don’t see a
    use
    for it. IMO, it should have never been there

  2. Because there is no real need for it. You have to know the parent’s
    type, might as well store it in the child’s context

  3. by design. Cleanup() is called well after the queue has been
    purged.
    You have pnp callbacks that let you purge the queue as you see fit
    (SelfManagedIoCleanup for instance) or queue callbacks (EvtIoStop). The
    contract for cleanup is that there is nothing else acting on or in the
    queue
    so it is safe time to free things lock free

  4. completely by design. Sorry, not going to change. The point here is
    that each object in its cleanup routine synchronizes and finishes all of
    its
    activity. By doing this, when the parent runs it can clean up
    /destroy/release the child objects without having to worry about
    synchronizing with the child object’s activities. For instance, a
    WDFWORKITEM will no longer have the work item queued when its parent
    gets a
    cleanup. Also, only cleanup() has a guaranteed ordering,
    destroy() does not since dangling references can cause out of order
    destruction.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Tuesday, December 05, 2006 6:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF object oddities

I’ve run into the following issues with Kmdf which surprised me. Some
may
be bugs, some may be design decisions. All can obviously be worked
around.
Unless I missed it, none are documented.

  1. In EvtCleanupCallback for a WDFWORKITEM, WdfWorkItemGetParentObject
    returns NULL.

  2. Why do we have WdfWorkItemGetParentObject at all? It seems a general
    WdfObjectGetParentObject would be useful.

  3. By the time EvtCleanupCallback is invoked for a WDFQUEUE object, it
    appears that any requests on the queue have been canceled (without
    invoking
    EvtIoCanceledOnQueue). If the framework were to wait until after
    calling
    cleanup to purge the queue, that would allow the caller to drain the
    queue
    as he sees fit.

  4. When an object that has child objects is deleted, the order of
    callbacks
    is Cleanup Children, Cleanup Parent, Destroy Children, Destroy Parent. I
    would prefer to see: Cleanup Parent, Cleanup Children, Destroy Children,
    Destroy Parent. This would give the opportunity to do global cleanup
    that
    requires the full existence of the child objects in the cleanup for the
    parent.

  • Dan.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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