From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Add support for a basic boot menu to the bios Date: Thu, 20 Sep 2007 08:02:21 +0200 Message-ID: <46F20CED.3000107@qumranet.com> References: <1189626953.16586.6.camel@localhost.localdomain> <46ED8B5B.40903@qumranet.com> <1190232486.10222.37.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Jeremy Katz Return-path: In-Reply-To: <1190232486.10222.37.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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/