Am 05.05.2009 09:48, schrieb Carl-Daniel Hailfinger:
On 05.05.2009 09:42, Patrick Georgi wrote:
Am 05.05.2009 06:55, schrieb ron minnich:
There is actually no change to the find code in src/lib, in fact; that code also walks all of rom, in strides of 'align'. If we ever worry that 16 bytes is too small an increment we can change it at the command line, when we create a cbfs archive.
In that case, I'll have to revert a change made to lib/cbfs.c to walk the chain of files (instead of a brute force walk through the whole image). SeaBIOS will have to do likewise.
And that means, that we either need some cache about file locations in the readers, or certain operations will be very expensive (eg. SeaBIOS looking for all kind of pci*roms)
Doesn't zerofill solve that problem?
No, esp. with XIP images, we have no idea where images start and end. We have to look through the entire image for that.
I have some code for a "next" field that builds a chain without relying on "offset" and "len" (as the current chain walker do). That helps with a scenario like having two option roms right after another at the beginning of the ROM. The current walker would be confused by that. (it always looks for the next file header after the current file's data)
The "next" field has the disadvantage that we can't simply hot-update anymore, as we'd have to change data (instead of merely adding it).
And solutions like "use the 'unwritten bytes' marker (eg. 0xffffffff) as end-of-chain identifier", so it can be overwritten feel quite unclean, too.
Patrick