On Mon, 22 Feb 2010 12:42:48 +0100, Stefan Reinauer stepan@coresystems.de wrote:
Hi,
I rewrote the ASSERT() and BUG() implementations (src/include/assert.h) from scratch. The old one used different messages for preram and ram stages and would not print any warnings if CONFIG_DEBUG was disabled. In the case of CONFIG_DEBUG the code would die().
I wonder if that's the behavior we want. If something is bad enough to stop a system during development, maybe the warning should not be ignored completely when it happens in a productive system? I think we should always print a warning if the code is inconsistent.
Also, do we want to die() on an assert? I believe in most cases we don't.The worst case that happens when we run into a bug or assert situation is that we can not boot the system. But in some cases it's not that bad.. like in the mptable / acpi generator or some IOAPIC and SuperIO drivers. We might still be able to boot into a system and flash a new, fixed coreboot image, but in case of a die() we desperately brick the system. I think we should not do that.
What do you think?
I use die in raminit for memory compatibility checks. If the memory is not compatible, there is no use moving on...so we die().