corey.osgood at gmail.com
Wed Apr 16 12:41:37 CEST 2008
On Tue, Apr 15, 2008 at 12:14 PM, Myles Watson <mylesgw at gmail.com> wrote:
> > Code isn't interesting anyway; design / architecture is the problem
> > here.
> > > We are all professionals - we can come to a consensus. Right now,
> > > we're trying to figure out if we can make ELF perform the way we need
> > > it to perform. If we can be satisfied that it can, then we move on.
> > > If we cannot be satisfied, then the core team will have to make a
> > > decision to move on to another alternative, and then we can debate the
> > > details of SELF or something similar.
> > I agree.
> > So, what exactly *do* we need here, and *why*?
> I think a discussion of where we are and where we want to go would be
> helpful. Feel free to correct my status summary.
> Right now:
> 1. LAR format supports inclusion of:
> a. bootblock
> 1. Can be copied out, but only re-used in same size ROM
> b. ELF segments (multiple segments with one entry point, from an
> 1. Can't be extracted without losing entry point
This is something I don't understand, and probably would need a deeper
understanding of elf to understand, but maybe someone can explain it in a
nutshell. LAR parses the elf, extracts and manipulates the segments, and in
the process moves the entry point, right? But LAR has to have some sort of
entry point. So why can't we re-extract those segments, in LAR's new order,
and generate an elf header with LAR's entry point? So the elf file isn't a
binary equal to the original, but it runs just like it?
The other option, in my simple mind, would be to have LAR work like a
one-way archiver. If you want the LARchive's payload, LAR doesn't actually
extract the payload, it hands you a LARchive of just the payload, which can
then be added to another LARchive. Could that work?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot