Carl-Daniel Hailfinger wrote:
Hi Stefan,
since you seem to disagree violently with my conclusions although most of my conclusions are supported by the SELF wiki page, the only explanation is that you disagree with the SELF wiki page as well.
Not at all.
Wrong. Besides at least nrv2b is byte streaming.
Let me quote the current wiki page again: "The data section immediately follows the final entry in the segment table. Each block of segment data is written sequentially in this section." There is no mentioning of any alignment of the LZMA header at all and the "written sequentially" suggests there are no gaps. Please correct the wiki page if you disagree with it.
The wiki page did not mention it was complete either.
I am sorry it is not yet fool-proof enough for you to understand the goals of what we were working on. _Please_ stop nagging out of principle in this thread. All our compression algorithms are actually byte based, so you are completely discussing non-issues here. I wonder why you do this, because as far as I know, you were the one making the original lzma patch for coreboot - which unfortunately increased stack requirements by more than 16k. Something that will likely cause corruption on quite a number of boards. grep for "default STACK_SIZE" in the source tree. So let's please focus on fixing the actual issues possibly causing corruption before we discuss things that do not affect us.
Not at all. LAR takes care of the integrity. That's what i designed it to do.
Does it take care of the integrity of each SELF file as well?
Yes. As good as it does for any other file.
No because that would mean the file is corrupt and the lar checksum would catch that.
Scenario: You unpack a LAR. The extracted SELF file becomes corrupted somehow. You pack it into another LAR. That LAR now has a corrupt SELF file and you won't notice this during LAR creation.
Then you want to make SELF an exception here, compared to any other files in the LAR? How is corruption on disk not affecting the bootblock or any other file in the LAR, if you unpack it? Please, in your further discussion, also keep in mind that the current incarnation of LAR, besides all its broken section handling, also does not cover what you are talking about.
We did not try to catch disk errors during development. Neither did we try to catch mis-compilations or programming errors in our own code during runtime. Those are indeed outside of the scope and trying to catch them at runtime does not make a whole lot of sense.
Stefan