On Wed, Sep 17, 2008 at 11:50:07AM +0200, Peter Stuge wrote: > Robert Millan wrote: > > Void-ify a few return types that assume presence of a native > > coreboot table (and weren't actually used for anything). > > > > Signed-off-by: Robert Millan <[EMAIL PROTECTED]> > > Sorry, but I still don't understand the motivation for this. Tell me > why it's needed and I'll probably ack straight away. :)
With my Multiboot patch, one can no longer assume native coreboot tables unconditionally, since Multiboot might be used instead. coreboot_table.c, which provides get_lb_mem(), might not be linked in. However, arch_write_tables() uses get_lb_mem() unconditionally as its return value. But I observed that this value isn't actually used for anything. The caller (write_tables()) in turn uses it as return value, and then it is discarded by stage2(). So, rather than introducing a bunch of ifdefs to conditionalize this, my patches opt to remove it. This way both build options get the size benefit. Also, IMHO it didn't make much sense for a function that generates different types of data structures (write_tables()) to have a return value that is specific to only one of these. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
