Janitorial Task - Get rid of TAG_NONE

[Steven Edwards]

Hi,
Royce suggested that we need to get rid of TAG_NONE and I remeber EA posting a list of
tags a
while back so maybe its a good time to look at the issue again.
We have quite a few cases where ExAllocatePool() and ExAllocatePoolWithQuota() is calling
ExAllocatePagedPoolWithTag ( TAG_NONE ). I propose that we change the headers for these
two
functions to throw a compile error if we try to use them internally. We would still keep
it
implemented to support third party drivers but this way it will force developers to not
use them.
Thanks
Steven
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

[Alex Ionescu]

Steven Edwards wrote:
>  Hi,
> Royce suggested that we need to get rid of TAG_NONE and I remeber EA posting a list of
> tags a
> while back so maybe its a good time to look at the issue again.
> We have quite a few cases where ExAllocatePool() and ExAllocatePoolWithQuota() is calling
> ExAllocatePagedPoolWithTag ( TAG_NONE ). I propose that we change the headers for these
> two
> functions to throw a compile error if we try to use them internally. We would still keep
> it
> implemented to support third party drivers but this way it will force developers to not
> use them.
> Thanks
> Steven
>  
I agree, I was proposing something like this before too, so I'm glad
someone else is having the same idea. Instead of an error, maybe it
would be less annoying to have the Ex* functions throw out a DPRINT1...
Although that would be harder to trace.
Best regards,
Alex Ionescu

[art yerkes]

On Tue, 11 Jan 2005 13:59:36 -0500
Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   I agree, I was proposing something like this before
> too, so I'm glad
>  someone else is having the same idea. Instead of an error, maybe it
>  would be less annoying to have the Ex* functions throw out a DPRINT1...
>  Although that would be harder to trace. 
I don't like the printing way because we won't see them if they're called
only rarely.  The problem is code that's rarely executed also is likely
to be buggy.
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman

[Emanuele Aliberti]

Steven Edwards wrote:
>  Hi,
> Royce suggested that we need to get rid of TAG_NONE and I remeber EA posting a list of
> tags a
> while back so maybe its a good time to look at the issue again.
>  
http://reactos.com:8080/pipermail/ros-dev/2004-October/000378.html
The complete and most updated list of pool tags is in the file
"pooltag.txt", which is distributed with the PoolMon tool.
>  We have quite a few cases where ExAllocatePool() and
> ExAllocatePoolWithQuota() is calling
> ExAllocatePagedPoolWithTag ( TAG_NONE ). I propose that we change the headers for these
> two
> functions to throw a compile error if we try to use them internally. We would still keep
> it
> implemented to support third party drivers but this way it will force developers to not
> use them.
>  
I agree. Using untagged memory in kernel mode should be as fatal as
calling an unimplemented api.
Emanuele