* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080107 14:37]:
- Explicit free space covering lar member is fine, but to add any new
file to the archive, you have to erase the part covered by the exlusive space.
I don't think this is such a bit problem. Lar could remove this entry automatically, and recreate it. This is not more special code in lar than 1. But I start thinking that those two are pretty much the same in the end.
Yes, 1 and 2 are very similar. Your proposal is almost exactly what I had in mind. This "dummy" member would be removed once a file was added to the lar and the new entry would "overwrite" the dummy header. If we have an explicit size in the dummy header, we can point to the next header easily without having to stop. However, once we use an explicit size (setting some bits to 0), we have to erase the flash block to add a new entry in place of the dummy.
One plea though: What you describe usually only happens in a (currently) very rare case. That is the case where the "free" entry falls exactly on a flash block border.
Sure. We could have gaps to match up flash chip borders again. But this would re-introduce the problem of having to slowly walk a lot of space all the time.
Also, a potential update might as well exchange modules instead of just adding modules that were not there before. This will potentially shift all files in the lar, making it necessary to reflash the complete flash chip.
If we don't specify the size and keep all header entries (except magic) at value 0xff (all bits set), we still can write the new archive member without erasing because setting bits to 0 is always possible.
I am not convinced that safing flash erase cycles on bios updates is worth any design considerations. With one BIOS update a day, even deleting all flash blocks makes an average SST chip live at least 273 years. Do we need to extend that?
My proposed code change is not very flexible and really only serves as "end of interesting lar members" marker, but it is flash-friendly. Besides that, the code can be overridden so if you really want to look at the boot block, you can do so easily.
So that would be another runtime parameter?
What about a linked list in the header? Each file could explicitly point to the next file. If the pointer is 0 or -1, we stop.
Nice idea, but it may not work in all cases. Requirements for this to work cleanly are:
- The next pointer needs to have all bits set to 1 in the "stop pointer"
case, or it is impossible to add a member after the member with a stop pointer without erasing the sector containing the header with the stop pointer.
Oh my idea was to have the bootblock have a "next" member of -1. So there would always be a next member with 0 and 1 bits except for the last one (that will not allow you to put one behind it anyways, due to the reset vector on the x86 architecture)
Keep in mind that currently flashrom ALWAYS erases the complete flash chip except for some esoteric uses of the PMC PM49FL004.
No, I am not saying that we should keep a good concept out of LinuxBIOS just because one of the tools can not cope with this yet. But I fail to see the whole picture in the solution yet.
Stefan