ron minnich wrote:
On Jan 5, 2008 2:27 PM, Stefan Reinauer stepan@coresystems.de wrote:
Many seconds, though just scanning for an 8 byte signature at a 16byte aligned address?
it's depressing, but yes. It's also surprising.
That's a max of 32k string compares for every file that is _not_ found. Otherwise the number of compares is as high as the number of files in the lar minus 1. (ie. below 10)
no, it walks all of flash. see lib/lar.c -- or it seems to, it takes so long.
I can't find the behavior you describe in find_file(). It returns as soon as the file is found. Your delay must come from some other issue.
I suspect we are looking for files that are not there yet. Probably some normal/fallback stuff that our makefiles don't do yet, but stage1.c does. We should not look for fallback files if we don't compile any.
Or, we just add an "empty" lar with a correct header containing all of 0xff, having a correct size etc. Then we don't use pseudo headers at least. But this would break our design idea to allow files with holes in them so this should really be the last resort.
Stefan