Re: [PATCH] Add support for a basic boot menu to the bios

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Jeremy Katz wrote:
> On Sun, 2007-09-16 at 22:00 +0200, Avi Kivity wrote:
>   
>>> The attached patch adds support for a relatively basic boot device
>>> selection menu to the bochs bios code.  
>>>       
> [snip]
>   
>> This is nice!  Two comments:
>>
>> - it would be nice for qemu to provide the bios an indication if the 
>> '-boot' parameter was specified to qemu.  if so, the bios should skip 
>> the menu on first bootup, reducing the boot delay.  On subsequent boots 
>> the menu should be offered.  This is primarily useful in managed 
>> environments.
>>     
>
> While this could be nice, at the same time, -boot is going to be getting
> passed for a long time, even when it's no longer needed, just due to
> people not updating their tools.  So I almost think it's better to take
> the 3 second hit since it's going to be there every other time.  We
> could tweak it to be a little bit less, but 3 seems in line with what
> other BIOSes seem to do.
>
>   

I almost agree.  Let people upgrade their tools, they ought to have many
reasons besides the boot menu.


[we could add a -dont-show-boot-menu parameter to make this explicit,
but I don't think we should]

>> - coding this stuff in rombios32.c instead of rombios.c (with its 
>> strange idea of C) is *much* preferable for maintainability.  As far as 
>> i can tell, there is no reason not to do so, especially for code which 
>> is not called from the 16-bit OS.
>>     
>
> The code is called from the 16-bit OS, though.  

No, it's called from the boot code.  We're not returning to DOS after
int 19.

> It needs to be done
> after rom scanning has been done so that we can show network or not as
> appropriate.  And unless I'm missing something, calling into rombios32.c
> outside of rombios32_init() is going to add just as much
> hard-to-maintain code.
>   

Why?  the thunk into 32-bit mode can be shared and is a small piece of
code.  The boot menu is much larger and can potentially grow (to control
other options besides the boot device).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/