Implement the Swap Hash algorithm #1350
Conversation
Execute permission was inadvertently set on this document file. Remove that, as executing documentation isn't meaningful. Signed-off-by: David Brown <[email protected]>
The swap hash algorithm is a new algorithm that performs mostly the same steps as the swap-move algorithm, but with far fewer updates to the status area. This allows better support for large-write/small-erase devices. Signed-off-by: David Brown <[email protected]>
|
@d3zd3z, Hi this is a nice proposal but maybe there is a way to better support devices with large write block sizes. Suppose that instead of updating the progress status, the progress status is precalculated. E.g. a (running) crc32 would be calculated for each sector and this is written to the status before starting the upgrade. This can be written once taking into account the write block size. The progress is then determined by comparing the crc32 with the one that has been precalculated, as soon as a crc32 differs from the expected we have found the place where the upgrade has stopped, the upgrade can be restarted from this point. @danieldegrasse, for your info. |
|
@Laczen thanks for the suggestion. I'm not sure I see how this differs very much from what I'm proposing, though. A running sum, vs just having a hash of each block still needs to store that value. And, we still need to pre-compute them to make sure there aren't any collisions (and perhaps change a seed value). |
|
After going through the documentation once more I think it is basically the same. IMO this should be the standard method as it allows removing the swap status from the image slots. |
gustavonihei
added
area: docs
|
@d3zd3z As I went through this RFC I found it as outstanding mechanism. |
|
@nvlsianpu writes:
They are computed and written once, before any flash operations are started. There is no update to them between slide and swap, as the same hashes apply. I probably have to think a bit about hashes and encryption, though, as using encryption might require some trickery to avoid having to have twice as many hashes. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
Pushing this early to get some review on the docs.