<div dir="ltr">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.<div><br></div><div>So let's backup and look at the big picture:</div><div><br></div><div>1. Fixed delays are annoying. They are always too short or too long (sometimes both)</div><div><br></div><div>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.</div><div><br></div><div>3. Their other use case is to provide an option in the bootloader for ipxe (ipxe.lkrn or ipxe.efi)</div><div><br></div><div>4. Another common use case is for actual network roms for real hardware. more on this in a bit.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>I propose the following courses of action:</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div><div>Thanks for considering this, I know it is a lot of commentary on a patch that adds two lines.</div><div><br></div>-- <br><div class="gmail_signature"><div>--</div><div><div>Ben Hildred</div><div>Automation Support Services</div></div><div>303 815 6721</div></div>
</div></div>