Mike.Sullivan at sun.com writes: > but it used to be that you weren't supposed to have DEBUG code make > it lots slower, as that discourages people from running DEBUG kernels > for normal use which does help. What 'lots' means these days I don't know, > but while I'd probably not worry much about asserts I'd probably put > things like > #ifdef DEBUG > /* spend minutes validating all my structures */ > #endif > > under another debug variables control that is not enabled by default.
That's certainly what we do in other areas. It's an important design note that the "variables" here should not be compilation-time symbols (i.e., no ifdef'd debug code) but instead be run-time tweaks; either global variables that can be poked by 'mdb' or special debug commands. One thing that's missing here is a translation of #define DEBUG into #undef NDEBUG for user space programs. I think that'd be a really welcome addition to the system. (Instead, user space developers tend to just modify the Makefiles to throw in "-DNDEBUG" shortly before delivery to ON or, worse, even toss "#define NDEBUG 1" into the source itself, and all those assert() calls turn into useless filler, even on subsequent DEBUG builds. There's room for improvement for the ambitious Makefile hacker.) > >What I believe tends to be frowned on though is spewing out lots of > >additional "tracing" type stuff to stdout/stderr or log files; but I'm > >not aware of any policy on that I can point you to. > > scary debugging messages like that also prevent people from running > DEBUG kernels, or just scare them, so they are also not wise (in > my view). +1 A good rule of thumb is that if there's nothing sane an ordinary user or administrator can do with the message, you should rethink whether and how to emit it. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
