Re: What policy for BUG_ON()?

[Michael Buesch <mbuesch@freenet.de>]

[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]

Quoting Kyle Moffett <mrmacman_g4@mac.com>:
> Then in most cases new statements would use BUG_CHECK, especially if
> they contain expensive unnecessary function calls or critical sections.
> 
> This would break the least amount of existing code, and provide both
> methods to kernel developers.

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()?

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.

I'm not talking of embedded systems, etc... .

-- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]