I want to use work item and don’t offer device object for my work item.
I find “ExInitializeWorkItem” and “ExQueueWorkItem” function can meet my requirement. but, these two functions have been marked as #pragma deprecated by MS.
Are there another functions to replace “ExInitializeWorkItem” and “ExQueueWorkItem”??
I don’t use “IoAllocateWorkItem” and “WdfWorkItemCreate”!!
thanks
can you explain the scenario where you don’t have a device object and don’t need a work item? typically when you need a work item, the underlying reason eventually ties back to some device object
d
Did you look at PsCreateSystemThread? It’s in the index of the WDK help
documents.
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Friday, January 14, 2011 9:36 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] about ExInitializeWorkItem
I want to use work item and don’t offer device object for my work item.
I find “ExInitializeWorkItem” and “ExQueueWorkItem” function can meet my
requirement. but, these two functions have been marked as #pragma deprecated
by MS.
Are there another functions to replace “ExInitializeWorkItem” and
“ExQueueWorkItem”??
I don’t use “IoAllocateWorkItem” and “WdfWorkItemCreate”!!
thanks
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
__________ Information from ESET Smart Security, version of virus signature
database 5788 (20110114) __________
The message was checked by ESET Smart Security.
I want to create work itme in DriverEntry.
So, I can’t get a device object to pass it to a work item.
=======================================
can you explain the scenario where you don’t have a device object and don’t need
a work item? typically when you need a work item, the underlying reason
eventually ties back to some device object
as we know, work item in linux does’t need a device object while creating a work item.
why do you need to create a work item in driver entry? if you have no device object in DriverEntry, this is not a legacy driver, which begs teh question, what kind of driver is this ? what are you trying to do (big picture, not the details you think you need to implement)?
d
thanks!!
===================================================
why do you need to create a work item in driver entry? if you have no device
object in DriverEntry, this is not a legacy driver, which begs teh question,
what kind of driver is this ? what are you trying to do (big picture, not the
details you think you need to implement)?
No there is no function that replaces it except for IoAllocateWorkItem.
The reason behind the change is that it was almost impossible to safely
cleanup and exit a driver with ExInitializeWorkItem, by associating a
device object the system can help do a better job.
I too have ported a lot of Linux driver code to Windows. This is a case
where trying to keep the code as close to Linux is a bad idea.
Reorganize the logic, to create the work item in AddDevice.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
> 1. It is a standard WDF driver and not a legacy one.
> 2. I don’t play to create a device object in DriverEntry.
> 3. I need to port a lot of linux code to windows and this code must be called in DriverEntry.
> so, I have to create work item without device object.
> 4. “ExInitializeWorkItem” function is marked as deprecated(but, I find it is still be used in WDK example code). so, I hope to find a much better function to replace it. Does such function exist?
>
> thanks!!
>
> ===================================================
> why do you need to create a work item in driver entry? if you have no device
> object in DriverEntry, this is not a legacy driver, which begs teh question,
> what kind of driver is this ? what are you trying to do (big picture, not the
> details you think you need to implement)?
thanks your idea.
I will do a test to pass “driver object” to IoAllocateWorkItem.
I want to verify whether IoAllocateWorkItem can work normally with a “driver object”.
==========================================================
No there is no function that replaces it except for IoAllocateWorkItem.
The reason behind the change is that it was almost impossible to safely
cleanup and exit a driver with ExInitializeWorkItem, by associating a
device object the system can help do a better job.
I too have ported a lot of Linux driver code to Windows. This is a case
where trying to keep the code as close to Linux is a bad idea.
Reorganize the logic, to create the work item in AddDevice.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Good HEAVENS no. Don’t do that.
Seriously… I can’t think of ANY reason that you absolutely HAVE to allocate the work item in DriverEntry, as opposed to EvtDriverDeviceAdd. Seriously.
You effectively continue posting “Please help me, the wings keep falling off my pig”…
and in return we’re asking you “ahhh… OK… why are you trying to put wings on a pig in the
first place?”
Peter
OSR
(WHERE is the PDF of my “Gluing Wings on a Pig” Pontification when I need it?? Gad! I thought I had it SOMEhwere. Where’s Dan when I need him!?!)
AH!!! Ask, and I shall receive. I should “sticky” this somehow:
http://www.osronline.com/downloads/pp_asking.pdf
Peter
OSR
As Peter already pointed out this is not going to work.
When converting a Linux driver to Windows you need to look at the logic
that accesses the device, and any interfaces or protocols the driver
exports. What you should not do is try to make a common code base.
You may be able to create some common functions, but in most cases if
you want a good reliable Windows driver, much of the code will be
different.
You seem wedded to keeping the Linux model of the driver, bottom line is
you will produce CRAP.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
> thanks your idea.
>
> I will do a test to pass “driver object” to IoAllocateWorkItem.
> I want to verify whether IoAllocateWorkItem can work normally with a “driver object”.
>
> ==========================================================
>
> No there is no function that replaces it except for IoAllocateWorkItem.
> The reason behind the change is that it was almost impossible to safely
> cleanup and exit a driver with ExInitializeWorkItem, by associating a
> device object the system can help do a better job.
>
> I too have ported a lot of Linux driver code to Windows. This is a case
> where trying to keep the code as close to Linux is a bad idea.
> Reorganize the logic, to create the work item in AddDevice.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> I will do a test to pass “driver object” to IoAllocateWorkItem.
Alternatively, you can pass a pointer to a kitchen sink in your call…
Anton Bassov
Yeah, but YOUR kitchen sink ain’t MY kitchen sink …
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, January 15, 2011 4:11 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] about ExInitializeWorkItem
I will do a test to pass “driver object” to IoAllocateWorkItem.
Alternatively, you can pass a pointer to a kitchen sink in your call…
Anton Bassov
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
__________ Information from ESET Smart Security, version of virus signature
database 5790 (20110115) __________
The message was checked by ESET Smart Security.
> Yeah, but YOUR kitchen sink ain’t MY kitchen sink …
Oh, come on, you are not going to turn it, again, to discussing a potty and other “strange topics” (or at least strange ones for a programming NG) the way you do it from time to time , are you…
Anton Bassov
You’ve GOT to love Anton helping keep this thread on topic. Or ANY thread, really.
Hey… I appreciate the help,
Peter
OSR
thanks
thanks everyone.
=====================================
As Peter already pointed out this is not going to work.
When converting a Linux driver to Windows you need to look at the logic
that accesses the device, and any interfaces or protocols the driver
exports. What you should not do is try to make a common code base.
You may be able to create some common functions, but in most cases if
you want a good reliable Windows driver, much of the code will be
different.
You seem wedded to keeping the Linux model of the driver, bottom line is
you will produce CRAP.
xxxxx@hotmail.com wrote:
- It is a standard WDF driver and not a legacy one.
Those two things are not related. I hate the term “legacy”, exactly
because it is way too ambiguous.
There are, fundamentally, two types of Windows drivers: PnP, and
non-PnP. “Non-PnP” is, in my view, a FAR better term for what others
call a “legacy” driver. People are still writing non-PnP drivers today,
and will continue to do so in the future. You can write either type in WDF.
The fundamental difference between the two is the point at which you
create your device object. With a non-PnP driver, the driver makes this
decision. The device object is created in DriverEntry, without any
further prompting by the system. With a PnP driver, the PnP system
makes this decision. The driver registers an AddDevice handler during
driver entry. When an ID appears that your driver can handle (as
specified in the INF file), the system will call your AddDevice routine,
and that’s where you create your device object.
The device object is the only way to receive requests. If you plan for
your driver to function beyond DriverEntry, you need to do one of the
two: either create a device object, or register an AddDevice handler.
There really is a fundamental difference in the way Linux and Windows
treats drivers. In Linux, you make requests of a driver. The driver
then has to figure out which of the devices it owns is being acted
upon. In Windows, you never interact with a driver. Instead, you make
requests of a device. The functions that handle that device happen to
reside within a driver, but that’s just an implementation detail. The
device is the fundamental unit.
- “ExInitializeWorkItem” function is marked as deprecated(but, I find it is still be used in WDK example code). so, I hope to find a much better function to replace it. Does such function exist?
DriverEntry is called at PASSIVE_LEVEL. It is hard for me to conceive
of a reason why you would need a work item in DriverEntry.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> I find “ExInitializeWorkItem” and “ExQueueWorkItem” function can meet my requirement. but, these
two functions have been marked as #pragma deprecated by MS.
For me, the deprecation of ExQueueWorkItem is a really nasty thing from MS’s side.
So, probably it is a good idea to suffocate the deprecation warnings with some another #pragma.
ExQueueWorkItem can be used in some library code where there is no device objects at all, for instance. Changing the APIs just to pass the device object there seems to be an overkill.
– Maxim S. Shatskih
Windows DDK MVP
Overkill for what, Max? That device object facilitates a guarantee that
your driver is still in memory when the last instruction of your worker
callback is executed. Without such a thing, your driver can’t be safely
unloaded.
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…
I find “ExInitializeWorkItem” and “ExQueueWorkItem” function can meet my
requirement. but, these
two functions have been marked as #pragma deprecated by MS.
For me, the deprecation of ExQueueWorkItem is a really nasty thing from MS’s
side.
So, probably it is a good idea to suffocate the deprecation warnings with
some another #pragma.
ExQueueWorkItem can be used in some library code where there is no device
objects at all, for instance. Changing the APIs just to pass the device
object there seems to be an overkill.
– Maxim S. Shatskih
Windows DDK MVP