[coreboot] Time for a new project

[Carl-Daniel Hailfinger]

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