[SeaBIOS] Running out of space in e/f-segments

[Avi Kivity]

  On 08/23/2010 01:57 AM, Kevin O'Connor wrote:
> On Sun, Aug 22, 2010 at 09:18:43PM +0300, Avi Kivity wrote:
>>   On 08/22/2010 08:40 PM, Kevin O'Connor wrote:
>>> On Sun, Aug 22, 2010 at 08:07:53PM +0300, Avi Kivity wrote:
>>>> I see that ld has some support for overlays, perhaps we can use that?
>>> The overlay support is basically just another way of manipulating the
>>> run-time addresses of the code at build time.  Unfortunately, it can
>>> only specify static addresses, and I don't think there is any safe
>>> static address that can be used (outside of 0xc0000-0xfffff).
>> Is that not useful?  We can push, say the IDE and virtio drivers to
>> overlay the same address range in the e/f segments, and have the
>> stubs pull them in as necessary.
> I guess you're describing a way of swapping parts of the BIOS in.  It
> could be made to work, but seems very complicated.

That's what overlay is, it used to be a hot method way back.  Why do you 
think it's complicated?  There's some support for it in ld.

> Relocating the code isn't that bad.  It should just be a matter of
> storing which parts of the code rely on a fixed address, and then
> updating those addresses at runtime.  Something like:
>
>      // Info provided by build
>      extern u32 Relocs[];
>      extern u32 NumRelocs;
>      extern void *OrigCodeAddr;
>      extern u32 CodeSize;
>
>      // Relocation code.
>      memcpy(newaddr, OrigCodeAddr, CodeSize);
>      for (i=0; i<NumRelocs; i++)
>          *(u32*)(newaddr + Relocs[i]) += (newaddr - OrigCodeAddr);
>
> If the code can be relocated, it should be okay to put it at the top
> of high memory.  Relocating should be more transparent than "swapping"
> to developers, as it wouldn't impose any limits on what can code can
> call other code.

Overlays are transparent too, you typically have stubs for overlaid code 
which call the overlay manager to swap the code in if necessary.  These 
stubs are generated automatically.

Relocation should work as well, and indeed has less constraints, but 
needs more build support.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.