lkml.org 
[lkml]   [2004]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: What policy for BUG_ON()?
Date
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]
\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.583 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site