[Etherboot-developers] [RFC] Relocation techniques...

[<ebi...@ln...>]

I'd really like to relocate etherboot, and there are currently
two techniques I can use.  I'd like to get a little more feedback
before I go forward with anything.

Technique 1. (Shared library)
 -  Build etherboot as a shared library, and keep the relocation
    information through runtime, so the code can be relocation.
 Impacts.
  - Larger codesize.
  - Must redesign the x86 bios calls to be a sperate piece that partly
    lives below 1MB.

Technique 2. (Virtual Adresses)
 - Use virtual addresses.  Either a true page table or just setup
   some segments.
  Impacts.
  - osloader needs to change how it copies data to memory.
  - pci devices need to call ioremap to find an appropriate
    address to access their devices at.
  - pci devices need to call virt_to_bus to compute addresses to
    pass to dma functions.
  - Must redisgn the x86 bios calls to be a seperate piece that partly
    lives below 1MB.


Technique 3. ( Fake Relocation)
 - Relocate a stub allowing for loading over etherboot.
 Impacts.
  - osloader needs to change how it copies data to memory.
  - No callbacks of any kind, are allowed.

For code size it is a toss up between using Virtual Addresses,
and Fake Relocation.  There are enough relocations and symbol name strings
left the Shared Library technique is clearly larger.

For amount of work for the Shared Library and Fake Relocation is pretty
clearly less than using Virtual Addresses.

For maximum flexibility the Virtual Address technique wins hands down
because it encompases most of the obvious effort needed to port
drivers to work on different cpu architectures.

I'm still thinking about it.

For me the low fruit is definitely solving the problem of compiling
in multiple drivers, and protocols and while still producing a working
binary.  For that the x86 bios calls definitely need to be clearly
seperated out.  (The ideal is to build a .com or .floppy image with
most of the drivers)

So I'm probably going to aim at implementing Virtual Addresses in the
long term.  If all of the drivers need to be audited for multicast
support anyway it should be much worse to get a handle on their
address space operations.  

Plus people have been wondering where the ioremap calls are anyway.

Eric