Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: What policy for BUG_ON()? | Date | Tue, 31 Aug 2004 19:32:39 -0400 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |