[coreboot] Time for a new project

[Stefan Reinauer]

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

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080413/531d9b63/attachment.sig>