On 16.01.2008 18:53, Jordan Crouse wrote: > On 16/01/08 10:41 -0700, Marc Jones wrote: > >> ron minnich wrote: >> >> >>> It seems like you've added two slightly more complicated ways to do >>> things where one simple one would have done: an end-of-entries LAR >>> header. Limiting payload segments to two is going to cause us trouble >>> now and forever, I think. And I'd still like to have a microcode/ >>> directory, and a rom/ directory, each with an undefined # of entries. >>> I think the LAR is going to be used in the future in ways we can not >>> imagine now. So solving those two cases won't help future uses. >>> >> I agree. I would like to use the LAR for microcode and for Geode VSA for >> starters. >> > > Not to pile on, but I agree 100%. > > The problem is that we've demonstrated conclusively in v2 that understanding > arbitrary blobs of non-payload data is mandatory for nearly architecture > we deal with. The initial design of LAR allowed for unlimited and arbitrary > blobs (either through careful design or luck). If now the limitations of LAR > are starting to outweigh the benefits, then we either have to account for > them, or scratch LAR and start over. >
OK, so you both say a full walk is OK as long as it doesn't take too long? Then we're indeed back to either an end-of-entries LAR member or a placeholder LAR member. Regards, Carl-Daniel -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
