[ipxe-devel] ROM timeout adjust

[Ben Hildred]

As I wrote earlier I have been reviewing debian's patches of ipxe (tanks to
Robin and michael one issue is resolved) and I am not sure I like their way
of suppressing the control-b time out, specifically their patch changes
ROM_BANNER_TIMEOUT_TICKS definition in arch/i386/prefix/romprefix.S so that
it is only defined if not already defined and define it as 0 in a local
configuration file (The local configuration file approach seems reasonable,
but I am not sure of their choice of variable) the definition of ...TICKS
is in terms of ROM_BANNER_TIMEOUT. Firstly I have no issue with the actual
code debian wrote, I am however not sure if it is a good idea overall.

So let's backup and look at the big picture:

1. Fixed delays are annoying. They are always too short or too long
(sometimes both)

2. One of debian's main uses of ipxe is to provide network roms for qemu (a
machine emulator) in this use case, the ipxe delay may depending on other
factors double the startup time of a virtual machine (I am sometimes slow
slow and have used a thirty second delay on a virtual machine that boots in
less than ten seconds do give me time to start vnc or terminal emulator).
On a production virtual machine 99% of the time you do not need or want any
delay here. On a debug setup five seconds may not be long enough as it is
common to need to switch to another window to view the virtual machine's
console or some log.

3. Their other use case is to provide an option in the bootloader for ipxe
(ipxe.lkrn or ipxe.efi)

4. Another common use case is for actual network roms for real hardware.
more on this in a bit.

5. A common use case is chainloading This presents both benefits in that it
is easy to replace the version of ipxe with a newer version (or a version
with different compile time options) and challenges in that we have less
control of the environment.

6. In a perfect world we (as users of ipxe) would never notice ipxe because
it would finish before it starts, never display a menu because it knows
what we want, and would display a prompt when we wanted it. So much for
living in a perfect world. The question becomes how close can we get to
this ideal and how hard do we want to try.

I propose the following courses of action:

1. in environments where there is the ability to receive pre-execution
input (command line, emulator settings, hardware buttons) that we disable
banner timeout in favor of pre-execution input. A simple way of doing this
quickly in the case of qumu would to create two boot-roms; one with no
delay and one with autoboot disabled and select between them by qemu
commandline options. A similar method could be explored with boot menu
options. Long term I would prefer to use command line parameters or
emulator variables (or hardware buttons on the network card).

2. In environments where pre-execution input is not available I would like
to make it easier to adjust the banner timeout at compile time by both
local configuration includes and compiler options. I think the pattern of
the debian patch has value for this, but I am not sure they picked the
right configuration variable.

Thanks for considering this, I know it is a lot of commentary on a patch
that adds two lines.

-- 
--
Ben Hildred
Automation Support Services
303 815 6721
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20150914/0f6bb40a/attachment.htm>