Re: What policy for BUG_ON()?

[Kyle Moffett]

On Aug 31, 2004, at 18:16, Michael Buesch wrote:
> So, back to the real world. ;)
> - Where do we insert BUG_ON()s?
> Only in places, where we are going to crash or corrupt data soon.
>
> - Do we insert "expensive unnecessary function calls" in a BUG_ON()?
> No we don't. Could you give a good example, which
> needs an expensive call inside a BUG_ON()?

BUG_ON(len != strlen(string));

I don't want the strlen() executed on an embedded machine every time
I hit that piece of code, heck, probably not even my server if string 
is big
or if this code is executed many times.

> In a shiny good world we expect BUG()s to never trigger. So I think
> it's a bit crazy to check for things that theoretically can't happen
> and waste tons of CPU cycles for this, with expensive calls.
> If we really want to check this while debugging, I think we
> should explicitely honor the DEBUG define in the code and have
> our own debug printk() that shows the mess.
>
> I think here's a general confusion about what BUG_ON() is intended
> for. I think (I'm not the author of it, so I can't say 100%. :) )
> it is _not_ for debugging while development. It is for checking 
> unpossible
> things, that blow up the whole machine if they trigger nevertheless.
> So I think it's wrong to let BUG_ON() depend on a DEBUG define, because
> DEBUG is, by definition, not enabled in the kernels people use.
> But I think we _want_ that people evaluate the BUG_ON()s.

Ok, so then we need an additional config directive:

CONFIG_EMBEDDED_NODEBUG

Then:

#ifdef CONFIG_EMBEDDED_NODEBUG
# define BUG_ON(cond) do { if (cond); } while(0)
# define BUG_CHECK(cond) do { } while(0)
#else
# define BUG_ON(cond) do { if (cond) BUG(); } while(0)
# define BUG_CHECK(cond) do { if (cond) BUG(); } while(0)
#endif

#ifdef CONFIG_DEBUG
# define DEBUG_ON(cond) do { } while(0)
#else
# define DEBUG_ON(cond) do { if (cond) BUG(); } while(0)
#endif

It's the _exact_same_ problem, with different definitions for which
mode is "debugging mode" in this particular case.  I agree with the
above email, but I think that for the embedded people, we should
define an extra macro that removes all excess tests, whether they
are expensive or inexpensive.  Then the BUG_ON() macro would
leave any checks in place in such a specialized compile, because
they may have required side effects.  A similar DEBUG_ON()
macro would be disabled for general users, but could be enabled
with DEBUG to provide the expensive checks, when a user is
experiencing problems.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/