[coreboot] [RFC] ASSERT
joe at settoplinux.org
Mon Feb 22 13:56:30 CET 2010
On Mon, 22 Feb 2010 12:42:48 +0100, Stefan Reinauer <stepan at coresystems.de>
> 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().
More information about the coreboot