question on CUV

OSR_Community_User · August 13, 2004, 3:38am

Hello. I know this is probably a futile question, but here goes anyways.

The DDK states that : “You can use CUV only if your sources file sets the
TARGETTYPE build macro equal to DRIVER and does not use the DRIVERTYPE
macro.”.

Fine, but what about shared driver code implemented by libraries, where the
TARGETTYPE is “DRIVER_LIBRARY”? Please tell me there is a workaround other
then copying the shared library source files into each project directory
which uses them, changing the main project’s sources to include the library
files, and recompiling.

Why doesn’t CUV work with DRIVER_LIBRARY TARGETTYPE? If there isn’t any
valid reason, I’d hope someone would change it for future versions.

kind regards,

Philip Lukidis

Peter_Viscarola_OSR · August 13, 2004, 4:46pm

Philip Lukidis wrote:

Why doesn’t CUV work with DRIVER_LIBRARY TARGETTYPE? If there isn’t any
valid reason, I’d hope someone would change it for future versions.

Oh, there’s a valid reason alright.

As it runs, CUV tracks the usage and state of various driver data
structures using an internal table. It does this tracking by address.
So, for example, if you initialize a spinlock in non-paged memory, CUV
remembers the address of that spinlock.

Cool, right?

Now, what happens when you have a bunch of code in a kernel mode DLL
that’s referred to by drivers A and B?

Each driver, A and B, are keeping separate tables on structure usage.
Thus, when the code in the kernel mode DLL intializes a spinlock (for
example) as a result of being called by driver A, the fact that this
spinlock as initialized is only known by the CUV code in driver A. When
driver B calls the kernel mode DLL, and that DLL now tries to use that
spinlock without having first initialized it, CUV would slap you with an
error.

This sort of error gets annoying after, oh, the 800th time, know what I
mean?

Anyhow, that’s the reason. Hope that helps,

Peter
OSR

OSR_Community_User · August 15, 2004, 3:51pm

From: PeterGV
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: Re:[ntdev] question on CUV
>Date: Fri, 13 Aug 2004 16:44:44 -0400
>
>Philip Lukidis wrote:
>>
>>
>>Why doesn’t CUV work with DRIVER_LIBRARY TARGETTYPE? If there
>>isn’t any
>>valid reason, I’d hope someone would change it for future versions.
>>
>
>Oh, there’s a valid reason alright.
>
>As it runs, CUV tracks the usage and state of various driver data
>structures using an internal table. It does this tracking by
>address. So, for example, if you initialize a spinlock in non-paged
>memory, CUV remembers the address of that spinlock.
>
>Cool, right?
>
>Now, what happens when you have a bunch of code in a kernel mode DLL
>that’s referred to by drivers A and B?
>
>Each driver, A and B, are keeping separate tables on structure
>usage. Thus, when the code in the kernel mode DLL intializes a
>spinlock (for example) as a result of being called by driver A, the
>fact that this spinlock as initialized is only known by the CUV code
>in driver A. When driver B calls the kernel mode DLL, and that DLL
>now tries to use that spinlock without having first initialized it,
>CUV would slap you with an error.
>
>This sort of error gets annoying after, oh, the 800th time, know
>what I mean?
>
>Anyhow, that’s the reason. Hope that helps,
>
>Peter
>OSR
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com

>To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi Peter, thanks for answering. First off, I’d like to apologize for the tone of my question. Deep down I realized there surely was, most probably, a good reason for it being the way it was.

However, I am still confused somewhat. I was not talking about an EXPORT_DRIVER (driver DLL), but a static library (DRIVER_LIBRARY). So in the case you mentioned, only 1 driver would be initializing any spin lock. And this would be known at link time, no? However, I am sure there are valid reasons for why it was done this way, I just don’t understand them (or I don’t see how what you said applies to a static library).

thanks,

Philip Lukidis

Take the effort out of being organized with MSN® Calendar. MSN Premium: Join now and get the first two months FREE*

Peter_Viscarola_OSR · August 17, 2004, 7:12pm

Philip Lukidis wrote:

Hi Peter, thanks for answering. First off, I’d like to apologize for
the tone of my question. Deep down I realized there surely was, most
probably, a good reason for it being the way it was.

Dude! No apologies necessary. Just means that you like the tool. And
I DO like hearing that!

However, I am still confused somewhat. I was not talking about an
EXPORT_DRIVER (driver DLL), but a static library (DRIVER_LIBRARY). So
in the case you mentioned, only 1 driver would be initializing any spin
lock. And this would be known at link time, no?

Sorry! That’s what I get for reading so fast and answering the “common”
question.

However, I am sure
there are valid reasons for why it was done this way, I just don’t
understand them (or I don’t see how what you said applies to a static
library).

Well, I’m on shakier ground here, Philip While there’s a valid
reason, you might not think it’s a very good one.

The main reason is simply that CUV hasn’t been tested in this
environment. In these early releases of CUV, the idea was to support a
clearly defined subset of potential targets, while everybody got
experience with the tool and ironed out any annoying problems.

I don’t know if CUV would work in the situation you outline, given that
it creates a number of globals. But if you’re a brave man, you don’t
mind trying something unsupported, and you’re looking for a
work-around… If you look at \DDK\BIN\makefile.new, you’ll see that
defining VERIFIER_DDK_EXTENSIONS in your build environment causes the
following statements to be executed:

C_DEFINES=$(C_DEFINES) -DVERIFIER_DDK_EXTENSIONS
ENTRY_SUFFIX=_DDK$(ENTRY_SUFFIX)
TARGETLIB=$(DDK_LIB_PATH)\DDK_EXT.LIB $(TARGETLIB)

I bet that if you add these to the end of the sources file (and not
define VERIFIER_DDK_EXTENSIONS) whatever driver you build want will get
built with CUV.

OBVIOUS CAVEAT: This work-around is not supported by Microsoft in any way.

If you try this, please do me the favor of letting me know (either on or
off list, your preference) how it works out.

Peter
OSR

OSR_Community_User · August 18, 2004, 11:31pm

----- Original Message -----
From: “PeterGV”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, August 17, 2004 7:10 PM
Subject: Re:[ntdev] question on CUV

> Philip Lukidis wrote:
> >
> > Hi Peter, thanks for answering. First off, I’d like to apologize for
> > the tone of my question. Deep down I realized there surely was, most
> > probably, a good reason for it being the way it was.
> >
>
> Dude! No apologies necessary. Just means that you like the tool. And
> I DO like hearing that!
>
> > However, I am still confused somewhat. I was not talking about an
> > EXPORT_DRIVER (driver DLL), but a static library (DRIVER_LIBRARY). So
> > in the case you mentioned, only 1 driver would be initializing any spin
> > lock. And this would be known at link time, no?
>
> Sorry! That’s what I get for reading so fast and answering the “common”
> question.
>
> > However, I am sure
> > there are valid reasons for why it was done this way, I just don’t
> > understand them (or I don’t see how what you said applies to a static
> > library).
> >
>
> Well, I’m on shakier ground here, Philip While there’s a valid
> reason, you might not think it’s a very good one.
>
> The main reason is simply that CUV hasn’t been tested in this
> environment. In these early releases of CUV, the idea was to support a
> clearly defined subset of potential targets, while everybody got
> experience with the tool and ironed out any annoying problems.
>
> I don’t know if CUV would work in the situation you outline, given that
> it creates a number of globals. But if you’re a brave man, you don’t
> mind trying something unsupported, and you’re looking for a
> work-around… If you look at \DDK\BIN\makefile.new, you’ll see that
> defining VERIFIER_DDK_EXTENSIONS in your build environment causes the
> following statements to be executed:
>
> C_DEFINES=$(C_DEFINES) -DVERIFIER_DDK_EXTENSIONS
> ENTRY_SUFFIX=_DDK$(ENTRY_SUFFIX)
> TARGETLIB=$(DDK_LIB_PATH)\DDK_EXT.LIB $(TARGETLIB)
>
> I bet that if you add these to the end of the sources file (and not
> define VERIFIER_DDK_EXTENSIONS) whatever driver you build want will get
> built with CUV.
>
> OBVIOUS CAVEAT: This work-around is not supported by Microsoft in any
way.
>
> If you try this, please do me the favor of letting me know (either on or
> off list, your preference) how it works out.
>
> Peter
> OSR
>
Hi Peter, thanks for answering again. Personally, FWIW, I certainly think
it a valid reason that a tool not be enabled with option X if said option
was not tested. No problem. I hope MS get to it someday.

Thanks for your workaround suggestion, but since I have to test only 1
project which uses this library, I have simply copied the library’s source
files into my main project’s sources file. That works fine with CUV.
Unfortunately, with things as they are, I don’t have time to take the more
adventurous route If I do later on, I will certainly provide
feedback.

thanks for your reply,

Philip Lukidis