[nvmewin] DBG question
Luse, Paul E
paul.e.luse at intel.com
Thu Apr 26 09:17:29 PDT 2012
This is a storport miniport we use StorPortDebugPrint and use nt!Kd_STORMINIPORT_Mask to control the volume. The DbgPrint I think was there before we implemented the StorPort calls really doesn't really belong anywhere in the driver anymore. Next patch we can clean this up (whoever does the next patch).
From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P
Sent: Thursday, April 26, 2012 9:05 AM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] DBG question
May I ask a fundamental question I see going on in the driver?
What is the rationale behind debug blocks like:
#if DBG
DbgPrint("Complete CID 0x%x on 0x%x\n",
pNVMeCmd->CDW0.CID,
pSQI->SubQueueID);
#endif
I would have expected DbgPrint() to be already compiled out in 'release mode' , something like:
#if "Microsoft Debug Build"
#define DbgPrint(x...) do { \
fprintf(stderr, "Function: %s(), Line: %d-> ", __func__, __LINE__); \
fprintf(stderr, x); \
fprintf(stderr, "\n"); \
} while(0)
#else
#define DbgPrint(x...)
#endif
And not need the extra "DBG" #if around it in the actual code blocks. Though the MSDN page for DbgPrint does not really say what happens if code is compiled in "debug" build vs "release" build.
Thanks,
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120426/bca12a06/attachment.html>
More information about the nvmewin
mailing list