[LinuxBIOS] [PATCH] v3: add a check for a termination member

[Carl-Daniel Hailfinger]

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 at 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:
>> 1. Explicit "stop searching here" marker or lar member.
>> 2. Explicit lar member covering the free space.
>> 3. 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.
>>     
>
>   
>> 2. 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