Messages in this thread | | | From | Michael Buesch <> | Subject | Re: What policy for BUG_ON()? | Date | Wed, 1 Sep 2004 00:16:30 +0200 |
| |
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 ]
[unhandled content-type:application/pgp-signature] | |