So after the lengthy discussion two weeks ago regarding ETW I decided it was
high time to convert a batch of kernel software to use ETW in the free
build. I expected the conversion process to take half a day or so. Three
days later the task is still not complete.
Here are some of the issues I ran into.
- white space appears to have some sort of meaning to the RUN_WPP statement
in a sources file. For example:
RUN_WPP=$(SOURCES) \
-km \
-func:gsDebugPrintEx(NULL, LEVEL, MSG,…)
Appears to confuse WPP, resulting on all of the LEVEL flags being undefined.
Everything is bliss if you amend the above statement as follows:
RUN_WPP=$(SOURCES) \
-km \
-func:gsDebugPrintEx(NULL,LEVEL,MSG,…)
This minor undocumented feature added about 1-day to the conversion process.
- As far as I can tell, Henry’s hint about how to use the !UNDOCUMENTED!
level and flag support in WPP does not work. If I amend my sources file as
follows:
RUN_WPP=$(SOURCES) \
-km \
-func:gsDebugPrintEx(LEVEL,FLAG,MSG,…)
And add the following to a global include file:
#define WPP_LEVEL_FLAGS_LOGGER(lvl,flags) WPP_LEVEL_LOGGER(flags)
#define WPP_LEVEL_FLAGS_ENABLED(lvl,flags) \
(WPP_LEVEL_ENABLED(flags) && WPP_CONTROL(WPP_BIT_##flags).Level >= lvl)
#define WPP_CONTROL_GUIDS \
WPP_DEFINE_CONTROL_GUID(someguid,\
(42F45982,818A,41dd,ADD3,DEB1A24DE686),\
WPP_DEFINE_BIT(flag1) \
WPP_DEFINE_BIT(flag2) \
)
I get the usual badness of the control bit flags being undefined. I also
get:
WPP_LEVEL_FLAG_ENABLED’: identifier not found, even with argument-dependent
lookup
And
‘WPP_LEVEL_FLAG_LOGGER’: identifier not found, even with argument-dependent
lookup
This consumed a day of randomly mucking with stuff. Lucky for me it was
concurrent, more or less, with the day spent discovering that white space
has meaning to RUN_WPP. Of course it would help if this stuff were actually
documented somewhere. I finally gave up and reverted to the ‘NULL’ syntax,
which is also undocumented, but it at least works.
-
The documentation and the ‘sample driver’ are horrible. The documentation
might as well not exist, and the sample tracedriver is so simple that, while
it works, it does not address any of the real-world issues people might
encounter. The only other sample in the ddk is one version of toaster, and
it too borders on the uselessly simple. -
Your debugprint routine can’t actually exist in your source code if WPP
is enabled. On reflection, this one was obvious, but guess what? It isn’t
actually documented anywhere. So you have to have a conditional compilation
flag to eliminate your debugprint function from your source code if you are
building for ETW. -
the ‘munged flags’ (those under the control of WPP_DEFINE_BIT) cannot be
used outside of calls to the munged function(s) defined in RUN_WPP. So for
example having code that does something like:
GlobalDebugType = flag1;
Results in an error because flag1 us undefined. Badness! WPP ought to
generate the premunged flag1 names as valid symbols. Oddly, this feature is
undocumented.
=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
I only wonder how you could make the decision after that