Hi,
Stefan and I spoke about various v3 stuff yesterday and it seems we have a slightly hackish solution which will avoid full LAR walks completely by changing the header format.
Basically, to avoid a full walk, you have to avoid requesting a nonexistant file. How? We have two sources of for such requests and they are easy to fix: - Looking for "normal/initram" when we should have looked for "fallback/initram". Simply make sure check_normal_boot_flag() returns a value matching the files you stored in the LAR. - Looking for "stage2" and "payload" segments which are not there. We can either add a "number of segments" field to the LAR header or we restrict the number of segments to 2.
Incremental caching of lookups can still save some time, but avoiding the full walk completely is going to save more time than anything else.
I will not be able to write any new code before the end of February (my thesis simply eats up all my time), but both points above should be really reasy to fix.
Regards, Carl-Daniel
On Jan 16, 2008 5:21 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Basically, to avoid a full walk, you have to avoid requesting a nonexistant file. How? We have two sources of for such requests and they are easy to fix:
- Looking for "normal/initram" when we should have looked for
"fallback/initram". Simply make sure check_normal_boot_flag() returns a value matching the files you stored in the LAR.
- Looking for "stage2" and "payload" segments which are not there. We
can either add a "number of segments" field to the LAR header or we restrict the number of segments to 2.
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.
So to me, this approach seems to be two special-case solutions to a problem which needs a general solution. And the general problem is this: when searching for an entry, we must know when we are at the last LAR header, so that we do not waste a full second searching all of FLASH for further entries which are not there.
I think we need to try again.
sorry
ron
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.
Marc
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.
Jordan
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
On Jan 16, 2008 2:12 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
OK, so you both say a full walk is OK as long as it doesn't take too long?
I think it is. I think it's really important that we handle the 'no such file' case in an extremely efficient, but *general*, manner. If we get this right, we're going to make very wide use of LAR.
Then we're indeed back to either an end-of-entries LAR member or a placeholder LAR member.
I agree.
ron
On 16.01.2008 23:40, ron minnich wrote:
On Jan 16, 2008 2:12 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
OK, so you both say a full walk is OK as long as it doesn't take too long?
I think it is. I think it's really important that we handle the 'no such file' case in an extremely efficient, but *general*, manner. If we get this right, we're going to make very wide use of LAR.
Then we're indeed back to either an end-of-entries LAR member or a placeholder LAR member.
I agree.
OK. Placeholder member or end-of-entries member?
Can everybody please state his personal opinion and the technical reasons for it, then we proceed? Bonus points if the opinion is delivered as a patch.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Marc Jones -
ron minnich