[coreboot] Time for a new project
stepan at coresystems.de
Sun Apr 13 17:00:34 CEST 2008
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.
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...
Size: 249 bytes
Desc: OpenPGP digital signature
More information about the coreboot