Re: Something else related to work item.
- From: "Doron Holan [MS]" <doronh@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 22 Mar 2006 23:13:38 -0800
you must not be looking very hard
C:\WINDDK\WDF\KMDF10\src\kmdf>findstr /s
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE *
1394\driver\pnp.c:
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&fdoAttributes, DE
VICE_EXTENSION);
AMCC5933\sys\AMCC5933.c:
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&fdoAttributes,
AMCC_DEVICE_EXTENSION);
[...]
WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE() was created before
INIT_CONTEXT_TYPE existed. It is still there so that existing samples that
were written before the new INIT call still work.
yes, you cannot control the queue type. the DDK says "Drivers must specify
DelayedWorkQueue."
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"KMDF_FW" <KMDFFW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4DFEF30C-1AE1-44C2-B3EB-4CFC47A93351@xxxxxxxxxxxxxxxx
Doron:
Hi, thank you for your reply. Based on what you said about the object
attribute, these two approaches are equivalent ways of initilizing it.
However, it seems that none of the samples of kmdf ddk use either
WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&woa, DEVICE_CONTEXT);
or
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&woa, DEVICE_CONTEXT);
Then I wonder how the device context info of the work item will be used by
KMDF framework, or the context info is only used by driver writers' own
use
and it's optional?
Meanwhile, for WDM work item object, we can specify whether we want to use
DelayedWorkQueue or CriticalWorkQueue for it. But it seems that we can't
specify that any more for KMDF work item anymore, is that right?
Thanks.
AT.
"Doron Holan [MS]" wrote:
there is no way to cancel a WDM work item once it is queued, so the
callback
will be called. What KMDF will guarantee is that by the time your
WDFDEVICE's EvtObjectCleanup() routine is called, that the work item
callback has been called and completed.
WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE() is just the 2nd part of
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(). For instance
WDF_DECLARE_CONTEXT_TYPE_WITH_NAME(DEVICE_CONTEXT, GetDeviceContext);
WDF_OBJECT_ATTRIBUTES woa;
WDF_OBJECT_ATTRIBUTES_INIT(&woa);
WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&woa, DEVICE_CONTEXT);
which is functionally the same as this code
WDF_OBJECT_ATTRIBUTES woa;
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&woa, DEVICE_CONTEXT);
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"KMDF_FW" <KMDFFW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:ACCA56B0-FFE4-448C-915C-EC27BE156CC9@xxxxxxxxxxxxxxxx
Ah, I got something else to ask. I understand that when a device is
removed,
the work itme related to it will also be removed since we specified
work
item's ParentObject to be the device. But in my case, when I remove my
usb
device, my work item callback routine is still called. Is it because I
didn't
specifiy correct ParentObject or there is something else we need to do?
BTW,
does anyone know how/when to use KMDF's
WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE() macro as there is no sample in
kmdf
ddk uses it and the short code in help file is not detailed enough to
be
helpful.
Thanks.
AT.
.
- Follow-Ups:
- Re: Something else related to work item.
- From: KMDF_FW
- Re: Something else related to work item.
- References:
- Re: Something else related to work item.
- From: Doron Holan [MS]
- Re: Something else related to work item.
- From: KMDF_FW
- Re: Something else related to work item.
- Prev by Date: Re: another BUILD question
- Next by Date: Unidrv's function order?! - SendFontCmd() & SendBlockData()
- Previous by thread: Re: Something else related to work item.
- Next by thread: Re: Something else related to work item.
- Index(es):
Relevant Pages
|
