[coreboot] Time for a new project
Stefan Reinauer
stepan at coresystems.de
Sat Apr 12 20:32:07 CEST 2008
Am 12.04.2008 um 04:16 schrieb Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net
>:
> 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.
Yes, on purpose. Because LAR takes care of that for the whole file. We
don't want duplicate information in SELF.
> SELF is missing a per-section compression algorithm specifier and if
> you
> introduce one...
Short answer: Not needed. The LAR compression type is good enough.
Using different compression algorithms within a SELF is a bad idea
anyways.
> 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.
And they will not happen more often than now.
>
>
>>> 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?
Those are blobs. In a few years everyone will be happy we got rid of
the current misconception, so no need to explain anything.
>
>
>>> 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.
>
Wrong. The SELF header is checksummed, too. If the SELF is not
consistent don't load any of it.
>>> 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.
>
Yes and by this simplify the code in all cases. It removes all the
special cases that we handle now and instead replaces them with a sane
solution.
>>> 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.
Just that it doesn't fit, because the concept is broken.
> Unfortunately, the current SELF+LAR
> proposal is not able to keep the design simple and still perform all
> tasks we currently use LAR for.
>
Wrong.
> 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
>
More information about the coreboot
mailing list