[coreboot] LAR TODO

[Carl-Daniel Hailfinger]

On 21.02.2008 00:06, Stefan Reinauer wrote:
> 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.

We created an archive format designed to store executables. When did we 
say that LAR was never designed to store executable code?


> And there was no sane reason for splitting an ELF file up into many 
> segments in the lar to begin with.

Splitting an ELF file into many segments which are compressed separately 
makes sense because it removes the need of a decompression scratch space 
which has been a problem in v2.


> 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.

The biggest reason not to do this is that it gives us zero improvements 
on the problem solving side. Remember the problem we were trying to 
solve? Reimporting that new sub-member type still is problematic.


>>> 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.

If you really want to have the complexity local to the problem domain, 
you need to move the entry point away from the top-level header because 
not all files added to the LAR have an entry point (think data files 
like the option table).


>>> - 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?

See above.


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

I'd say we first get a solid versioning infrastructure before we change 
the LAR format for other reasons.


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

Due to missing compat code?


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/