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