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

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

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

> Ken Yap wrote:
> > I'm not a big fan of callbacks either, it means designing another
> > interface which is slightly architecture dependent.
> 
> I guess, it depends on what kind of callbacks you decide to expose. I was mostly
> 
> thinking of making the networking driver available to the second stage
> loader. It should be possible to design a architecture-independent API to do so.
> 
> 
> If we have this ability, then it becomes trivial to do such things as:
> 
>   - write an externally-configurable graphical second stage loader. I think,
> this has been discussed a few weeks ago, and it seemed that the current API
> makes it difficult to fully implement this code. Mostly, because there is
> currently no good way to load configuration files and graphics files from the
> second stage code (or have I overlooked some feature in the API that provides
> this ability?)

Trivial.  You have a piece of preparation code that smashes all together into
one big image to load.  

Alternatively the type of NIC is supplied in the DHCP query.

>   - expose etherboot NIC drivers to the loaded Linux kernel. Admittedly, our
> drivers are not optimized for production use in a general-purpose OS, but this
> should be a great option for a rescue kernel that is guaranteed to run on any
> machine which can load etherboot.
> 
>   - maybe, some enterprising soul will even get around and implement full PXE on
> 
> top of etherboot. I don't particularly care for PXE, but requests for it keep
> being made.

For the people wanting PXE it is certainly a benefit.  

From a design standpoint I assume all code has bugs,
but that it actually works on the heavily exercised paths.

Further firmware is hard to update to fix bugs in your installed
base.  Depending on how hard it is to upgrade the ROMS on your
NIC this can range from very hard to almost trivial.  But even in the
best case it is still dangerous to upgrade your boot device, and can
leave a machine dead if the upgrade does not work properly.

So the design requirements are:
- Cope with small bugs in the firmware.
- You can't upgrade deployed firmware, on production machines.
- The firmware must be small.

Given that it is safer for the loaded image to bring along it's
network driver, and stack, because the loaded image can be recompiled
and fixed.  

Additionally when information is provided it is better to provide that
information in a table, instead of using callbacks.  Because if the
callback goes wrong your system is dead.  If the table is wrong the
loaded software can detect the bug and work around it.

So once you are into pure software land I don't have problems with
callbacks, but until that point I feel they should be avoided.

Eric