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.
On 12.04.2008 20:44, Stefan Reinauer wrote:
Am 12.04.2008 um 07:52 schrieb Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 12.04.2008 15:55, Patrick Georgi wrote:
Am Samstag, den 12.04.2008, 13:16 +0200 schrieb Carl-Daniel Hailfinger:
SELF is missing a per-section compression algorithm specifier and if you introduce one, you have a compression algorithm specifier both in LAR and in SELF. If you remove it from LAR, you have no way to store
BSS is defined to be the implicit-RLE-0 compressor. Everything else probably defaults to a single one (LZMA).
I don't know whether we really want to make building an uncompressed image impossible.
No, instead we make this stuff well defined.
Let me quote the current SELF wiki page: "CODE and DATA sections _may_ be compressed". Without a way to find out whether these sections are compressed, compression is totally undefined. Feel free to edit the wiki page to make this well-defined.
Sorry, you misunderstood. The obvious speed penalty comes from unaligned accesses. Some architectures can't even handle unaligned accesses at all.
Uhm, once the LAR header is aligned (it is), and of a size multiple the alignment size, the data is aligned, too - right?
The LAR header is aligned, the SELF headers are aligned as well, but the individual SELF chunks containing LZMA headers are not.
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.
Wrong. Checksums say nothing about corrupt internal SELF structure. The LAR parser has the ability (well, at least in theory) to check for overlapping archive members right now. With SELF, a corrupt SELF header can reference arbitrary places in the archive and a pure LAR parser can't find that out because it does not parse SELF by design.
What kind of corruption do you refer to? The one that happens before the file it put in the LAR? (so the LAR checksum matches) There shouldn't be any, if the SELF creator works right.
If the SELF creator works right. Exactly. If it produces random garbage, LAR has no way to know.
That's a bogus reason. The current code could just as easily produce garbage and checksum it right. Making per segment checksums does not improve the situation at all.
My point here was not about checksums. LAR currently treats ELF files as binary blobs if you don't preparse them. AFAICS Ron wanted the preparsing as sort of a security mechanism to determine whether the ELF looks like a real ELF file. If SELF is treated as a blob by LAR we lose that advantage.
The one that happens later should be caught by LAR's checksum.
And just like the SELF creator, the LAR creator could have a bug and create broken structures.
Indeed. However, right now a LAR verifier could find all broken structures. With the new design, we would need a LAR+SELF verifier.
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?
And since a pure LAR parser does not understand SELF, you need a combined SELF+LAR parser to know whether the ROM has a chance to boot.
Does your parser also check if the bootblock starts with RET? Or solve the halting problem?
No, but it can make sure that accessing any LAR member will not try to reference memory outside the LAR member. Accessing a SELF chunk can easily reference memory outside the LAR member and even outside the archive.
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.
The bootblock and initram are executable files. They should be contained in SELF as well (and that means you should be able to state that the code is XIP). Tables which should be loaded to a given address in memory
the bootblock isn't loaded by a SELF parser - even if it gets a suitable header, it would implicitely be XIP.
OK, agreed for the bootblock. But how do you mark initram XIP?
Initram is not segments now either.you know its xip. To lar its just a hunk of data
OK.
Regards, Carl-Daniel