etherboot-developers

[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

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

[Markus G. <ma...@gu...>]

Eric W. Biederman wrote:
> Technique 1. (Shared library)
> Technique 2. (Virtual Adresses)
> Technique 3. (Fake Relocation)
> 
> 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.

I agree with you, that virtual addresses are the most desirable solution, 
although not neccessarily the easiest one. Whenever this discussion came up in 
the past, I always saw two crucial arguments that ultimately pointed towards 
implementing virtual addresses:

  - code size is crucial. While these days it is relatively common to have at 
least a couple of tens of kilobytes of available ROM space (my original design 
goal for etherboot was to fit into 8kB), there are still enough constraints to 
make it important to carefully manage code size -- especially if you plan on 
making these changes in order to be able to compile multiple drivers into the 
same image.

- the most interesting reason that I could see for this kind of change was the 
prospect that it would allow proper call backs into the driver. Once that is 
possible, there are all kinds of cool things that we can implement.



Markus


-- 
Markus Gutschke
3637 Fillmore Street #106
San Francisco, CA 94123-1600
+1-415-567-8449
ma...@gu...

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

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

Markus Gutschke <ma...@gu...> writes:

> Eric W. Biederman wrote:
> > Technique 1. (Shared library)
> > Technique 2. (Virtual Adresses)
> > Technique 3. (Fake Relocation)
> > 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.
> 
> I agree with you, that virtual addresses are the most desirable solution,
> although not neccessarily the easiest one. Whenever this discussion came up in
> the past, I always saw two crucial arguments that ultimately pointed towards
> implementing virtual addresses:
> 
>   - code size is crucial. While these days it is relatively common to have at
> least a couple of tens of kilobytes of available ROM space (my original design
> goal for etherboot was to fit into 8kB), there are still enough constraints to
> make it important to carefully manage code size -- especially if you plan on
> making these changes in order to be able to compile multiple drivers into the
> same image.
> 
> - the most interesting reason that I could see for this kind of change was the
> prospect that it would allow proper call backs into the driver. Once that is
> possible, there are all kinds of cool things that we can implement.

I agree but I am unlikely to be one of those working on callbacks.  I do
not believe callbacks are generally viable.  Or at the very least callbacks
can easily lead to code being executed in ways it was not tested in,
and breaking at inoportune moments.

Plus there is some amount of bloat in just forwarding the callbacks to
the appropriate location.

Ken's approach of just changing the DHCP configuration options is
interesting, as it really keeps exactly virtually the same interface
to the outside world, while providing most of the benefits of
callbacks.

Now that etherboot is reporting it's primary NIC a loaded image can be
reasonably expected to actually support the hardware. 

There are some interesting things I would like to see and after I
solve the easy problems I will see how the very interesting features
are implemented.

Eric