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