>From on-discuss-bounces at opensolaris.org Thu Apr 16 08:59:29 2009
>> Is there any document which describes the rules what kind of debug
>> behaviour is allowed for OS/Net DEBUG builds ? For example:
>> - Is it allowed to call |assert()| in DEBUG builds, even if this means
>> that vital components (e.g. /usr/bin/sh or SMF) of a system will fail in
>
>The Kernel is covered in ASSERT calls in DEBUG builds and there is
>nothing more critical than that since if those asserts in kernel trip
>the result is a panic.
>
>It is understood that a DEBUG kernel is slower than a non DEBUG one
>since there is a lot more code running and by default a lot more kmem
>checking.
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.
>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).
Mike
