On 07.01.2008 14:01, Stefan Reinauer wrote:
Carl-Daniel,
thanks for bringing this up.
You're welcome.
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080107 10:40]:
The bootblock will always be the last member of the lar. We also try to fill the lar from the bottom up. That means unless the lar is completely full, we will walk an empty are in 16 byte increments. Since we know the location of the boot block (top of flash) and we also know we never have to lookup or load the bootblock during LB execution, there should be an easy way to specify "from here to the beginning of the bootblock there will be no file" which is equivalent to "stop searching here". The "no file till bootblock" functionality can be implemented in three ways:
- Explicit "stop searching here" marker or lar member.
- Explicit lar member covering the free space.
- List free space somehere in flash.
Two of these ways fail in practice: 3. Listing free space in flash means erasing and/or rewriting that list everytime the lar changes. The only reasonable place for such a list would be the bootblock and we don't want to touch it during partial reflash.
- 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. 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.
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.
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. - The next pointer needs a way to be changed to a "stop pointer" without erasing (so the "stop pointer" must have at least one bit set to 0), or it is impossible to remove one archive member (and setting the previous next pointer to "stop pointer") without erasing the sector containing the header of the last member before the erased member. Conclusion: All bits must be set to 1 in the "stop pointer" value for adding to work, but at least one bit must be set to 0 in the "stop pointer" value for erasing to work. That's a conflict.
This way we would not lock out the "bootblock" file in our lar search.
The "stop member" recognition could be disabled on a per-case basis.
Regards, Carl-Daniel