CUV is complaining about an uninitialized spinlock in driver A. The
spinlock is initialized in driver B. Driver B is layered above driver A in
a device stack. The two drivers share a critical data structure (pointer
passed via FileObject->FsContext), and the spinlock resides in this
structure.
This scheme works just fine in practice. I’d rather not tear up the code to
isolate the spinlock in one driver or another if I don’t absolutely have to.
The questions I have are:
-
Is CUV doing me a favor by catching something that is actually bad, or
am I just running into a limitation of CUV not being able to see across the
two drivers?
-
Could this cause problems in a future HCT? The current drivers are
signed.
Chris Myers
MessageThere have been warnings about CUV not working with driver libraries
(such as NDIS) and this is roughly what you are doing. By the same token I
would consider redesigning things to put all the code that synchronizes
access to the structure in one driver and provide an interface (device
interface, IOCTL to a pointer block, whatever) for the other driver. Doing
this will make it easier to review and if you need to change things this
encapsulates the model.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Chris Myers” wrote in message news:xxxxx@ntdev…
CUV is complaining about an uninitialized spinlock in driver A. The
spinlock is initialized in driver B. Driver B is layered above driver A in
a device stack. The two drivers share a critical data structure (pointer
passed via FileObject->FsContext), and the spinlock resides in this
structure.
This scheme works just fine in practice. I’d rather not tear up the code to
isolate the spinlock in one driver or another if I don’t absolutely have to.
The questions I have are:
1. Is CUV doing me a favor by catching something that is actually bad, or
am I just running into a limitation of CUV not being able to see across the
two drivers?
2. Could this cause problems in a future HCT? The current drivers are
signed.
Chris Myers
Message
This is just a limitation of CUV. If you look under “CUV Limitations” in the
DDK docs your exact scenario is called out as something that CUV will
falsely report as an error.
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Chris Myers” wrote in message news:xxxxx@ntdev…
CUV is complaining about an uninitialized spinlock in driver A. The
spinlock is initialized in driver B. Driver B is layered above driver A in
a device stack. The two drivers share a critical data structure (pointer
passed via FileObject->FsContext), and the spinlock resides in this
structure.
This scheme works just fine in practice. I’d rather not tear up the code to
isolate the spinlock in one driver or another if I don’t absolutely have to.
The questions I have are:
1. Is CUV doing me a favor by catching something that is actually bad, or
am I just running into a limitation of CUV not being able to see across the
two drivers?
2. Could this cause problems in a future HCT? The current drivers are
signed.
Chris Myers
Thanks, Scott. I guess I should have RTFM :-).
Chris Myers
-----Original Message-----
From: Scott Noone [mailto:xxxxx@osr.com]
Sent: Thursday, September 23, 2004 11:40 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] sharing a spinlock between two drivers
Message
This is just a limitation of CUV. If you look under “CUV
Limitations” in the
DDK docs your exact scenario is called out as something that CUV will
falsely report as an error.
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Chris Myers” wrote in message
>news:xxxxx@ntdev… CUV is complaining about an uninitialized
>spinlock in driver A. The
>spinlock is initialized in driver B. Driver B is layered
>above driver A in
>a device stack. The two drivers share a critical data
>structure (pointer
>passed via FileObject->FsContext), and the spinlock resides in this
>structure.
>
>This scheme works just fine in practice. I’d rather not tear
>up the code to
>isolate the spinlock in one driver or another if I don’t
>absolutely have to.
>The questions I have are:
>
>1. Is CUV doing me a favor by catching something that is
>actually bad, or
>am I just running into a limitation of CUV not being able to
>see across the
>two drivers?
>
>2. Could this cause problems in a future HCT? The current
>drivers are
>signed.
>
>Chris Myers
>
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as:
>xxxxx@quatech.com To unsubscribe send a blank email to
>xxxxx@lists.osr.com
>
Point taken, but I feel that changing the code just for the sake of elegance
would entail too much risk. So long as I’m not coloring outside the DDK
lines, I’m satisfied.
Chris Myers
-----Original Message-----
From: Don Burn [mailto:xxxxx@acm.org]
Sent: Thursday, September 23, 2004 11:36 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] sharing a spinlock between two drivers
There have been warnings about CUV not working with
driver libraries (such as NDIS) and this is roughly what you
are doing. By the same token I would consider redesigning
things to put all the code that synchronizes access to the
structure in one driver and provide an interface (device
interface, IOCTL to a pointer block, whatever) for the other
driver. Doing this will make it easier to review and if you
need to change things this encapsulates the model.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Chris Myers” wrote in message
>news:xxxxx@ntdev… CUV is complaining about an uninitialized
>spinlock in driver A. The spinlock is initialized in driver
>B. Driver B is layered above driver A in a device stack. The
>two drivers share a critical data structure (pointer passed
>via FileObject->FsContext), and the spinlock resides in this structure.
>
>This scheme works just fine in practice. I’d rather not tear
>up the code to isolate the spinlock in one driver or another
>if I don’t absolutely have to. The questions I have are:
>
>1. Is CUV doing me a favor by catching something that is
>actually bad, or am I just running into a limitation of CUV
>not being able to see across the two drivers?
>
>2. Could this cause problems in a future HCT? The current
>drivers are signed.
>
>Chris Myers
>
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as:
>xxxxx@quatech.com To unsubscribe send a blank email to
>xxxxx@lists.osr.com
>