[coreboot] LAR TODO

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
>>
>> These two are relevant for being able to use the file, and they are lost
>> while unpacking:
>>
>>         u64 entry;
>>         u64 loadaddress;
>>   
>
> That's an unpacking problem, not a packing problem and does not 
> require any LAR header format changes. But I agree entry and 
> loadaddress should be preserved on unpacking.

It's a design problem. We are trying to make an executable file format 
out of an archiver file format. It was never designed to be that. And 
there was no sane reason for splitting an ELF file up into many segments 
in the lar to begin with.

All I do is trying to back out bad design decisions.


>>
>> So, since we can not do a good job recreating an ELF, we should clean up
>> our design and do the following:
>>
>> Drop entry and load address out of the LAR format. Instead, we define a
>> "coreboot native blob format" which looks like the following and pack
>> it _into_ the lar.
>>
>> +--------------------+
>> | MAGIC              |
>> +--------------------+
>> | Entry              |
>> +--------------------+
>> | Number of Segments |
>> |    (consecutive)   |
>> +--------------------+
>> | SEGMENT 1/n        |
>> | +----------------+ |
>> | | Load Address   | |
>> | +----------------+ |
>> | | Len (needed?)  | |
>> | +----------------+ |
>> | | Compress. Type | |
>> | +----------------+ |
>> | | Data           | |
>> | |                | |
>> | +~~~~~~~~~~~~~~~~+ |
>> +--------------------+
>> |      ....          |
>> +--------------------+
>> | SEGMENT n/n        |
>> | +----------------+ |
>> | | Load Address   | |
>> | +----------------+ |
>> | | Len (needed?)  | |
>> | +----------------+ |
>> | | Compress. Type | |
>> | +----------------+ |
>> | | Data           | |
>> | |                | |
>> | +~~~~~~~~~~~~~~~~+ |
>> +--------------------+
>>   
>
> It looks nice at the first glance, but I still do not really like it. 
> Call it a bad gut feeling.
>

Ok, so lets do it like this. It is the cleaner design. Reasons should 
win against bowel.


>> Such a file could be unpacked and repacked, and a single ELF file always
>> stays a single file, and is not falsely split into several files.
>>
>> This has several advantages:
>> - we don't have an entry point field in lar that is bogus in most lar
>>   entries. Instead we have one per "blob", which is logically the right
>>   thing to do
>>
>> - The format is well defined and non-lossy.
>>
>> - LAR as a format stays blob-agnostic. Enhancements to the way a blob is
>>   saved in a lar does not break the lar file format, but at most the
>>   blob file format.
>>
>> - It's more solid
>>
>> - It takes complexity out of the LAR complex. Which is good!
>>   
>
> It only moves complexity and the interdependencies are really nasty.
>

There are no interdependencies. And it moves the complexity where it 
belongs: Locally to the problem domain, not globally to the central data 
structure.


>> - It's more modular.
>>
>>
>>
>> I really think that not parsing ELF during coreboot run-time is the
>> way to go. But we should not misuse LAR as an archive format for things
>> and features that it was not made for. We buy us (hidden) complexity
>> otherwise.
>>
>> Dropping ELF is a a new idea. And as such it deserves a new concept that
>> is well-thought, consistent and simple in its own.
>>   
>
> Agreed. I still would like to discuss the new proposed lar format 
> further, though. Especially the aspect of LAR header versioning 
> because the new header would be in no way compatible to the old one.

Ok, any reasons besides bad guts?

Versioning is another issue, and yes, now that we finally have real 
actual hardware running, we should think about versioned headers.

Keep in mind that in the current lar format versioned headers are 
completely bogus because you can not unpack a lar anyways.


Stefan

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080221/e57cbdd6/attachment.sig>