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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel