On 12.04.2008 10:28, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
NAK. This design is so unfinished it is not even funny. Hint: Certain fields in the LAR header are there for a reason (guess which).
Yes, and because that concept is so incredibly broken beyond belief, we fixed it up at the summit. Those completely archive-unrelated fields which just sneaked into lar because we did not do our reviews thoroughly enough will finally go away again. Way to go.
SELF is missing a checksum for each uncompressed segment.
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 compressed data in a LAR directly. You can work around that by wrapping every file with a SELF header, but then SELF becomes a generic file container and violates your statement that "SELF is the container for executable files".
There's also an obvious speed penalty for SELF (guess why).
The opposite. There's a speed win because we do less work in lar walks.
Sorry, you misunderstood. The obvious speed penalty comes from unaligned accesses. Some architectures can't even handle unaligned accesses at all.
The concept of PIC is missing completely.
Because it is not needed.
So you propose to handle some executable code (bootblock, raminit) just with LAR and not with SELF? How are you going to explain that concept a few years down the road?
A LAR parser can't figure out if the archive is corrupt.
Plain wrong. There's checksums in the lar, and that wont change. Even here you will see a reasonable speed-up because you don't have to load 3 segments to memory before you find the 4th being corrupted.
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.
Ron once stated the ability to figure out whether the ROM is corrupt before you flash it is one of the key features of LAR. SELF completely destroys that feature.
Not at all - The opposite: It makes lar finally more solid again. The feature of checksumming (could have) worked nicely with the very first version of lar that I wrote. Just the actual checking was not in place as it is a minor issue when you can't even boot.
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.
We might as well kill LAR completely and move to SELF only (and then SELF slowly will become a bad reinvention of LAR).
You are seriously misunderstanding the concepts of LAR and SELF. While LAR is an archiver of arbitrary(!) files, SELF is the container for executable files. Mixing these two up was the biggest mistake in the history of the young LAR, making things irreversible and fragile.
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 are by definition NOT code, yet you have to supply a load address (something that will only be available to SELF), so SELF is in no way "the" container for executable files, but a container for files which need at least part of them loaded to a given address.
When writing software, one should think about the problem that is going to be solved. The reason for unpacking segments was to get rid of the ELF loader and being able to streamload code. This has nothing to do with anything I designed LAR for and the fact that the implementation was married into LAR was obviously a foul hack.
I agree that the current LAR implementation and design is a one-size-fits-all compromise. Unfortunately, the current SELF+LAR proposal is not able to keep the design simple and still perform all tasks we currently use LAR for.
I'm all for revising an existing design as long as the new design is better or equal in all aspects. LAR+SELF probably can be beaten into shape, but it won't resemble the current proposal.
Regards, Carl-Daniel