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

[<ke...@us...>]

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

With VM you could also do funky things like dynamically mapping in one
out of a large set of drivers to reduce runtime footprint even when you
have a lot of storage for the combined binary.

Question: what virtual address would you have Etherboot live at? Would
it not preclude loading target code at that address range? I guess maybe
not, you could have a different VM mapping for the target code and then
switch it back on exiting Etherboot. Or maybe have Etherboot run in the
highest available pages in VM and hopefully nobody ever wants to load
target code there.

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

Yes, it's annoying that the BIOS calls are inline, limiting the total
memory space of the 32-bit code to 64kB.