From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LDMb0-0005AH-93 for qemu-devel@nongnu.org; Thu, 18 Dec 2008 12:23:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LDMay-00057N-9H for qemu-devel@nongnu.org; Thu, 18 Dec 2008 12:23:33 -0500 Received: from [199.232.76.173] (port=51082 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LDMay-00053A-1I for qemu-devel@nongnu.org; Thu, 18 Dec 2008 12:23:32 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:50183) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LDMap-00034L-HI for qemu-devel@nongnu.org; Thu, 18 Dec 2008 12:23:25 -0500 Received: by qyk13 with SMTP id 13so1143643qyk.10 for ; Thu, 18 Dec 2008 09:23:20 -0800 (PST) Message-ID: <494A8704.6030102@codemonkey.ws> Date: Thu, 18 Dec 2008 11:23:16 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] x86: Manage BIOS boot menu via command line References: <494A4A55.2090700@siemens.com> <200812181620.01572.paul@codesourcery.com> <494A7A46.7040300@codemonkey.ws> <494A80DE.6020601@siemens.com> In-Reply-To: <494A80DE.6020601@siemens.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org, Gleb Natapov Jan Kiszka wrote: > Anthony Liguori wrote: > >> Paul Brook wrote: >> >>> >> Or -boot cad,prompt=[on|off] >> > > -boot currently takes arbitrary characters from a-z. Adding some > extension means changing a lot of code (the users are unfortunately not > well structured right now). Our user interface should not be dictated by our lack of structure internally. That said, I don't believe it's as bad as you may first think. If you parse the parameters of the string in vl.c, you can construct a new string that just contains "cad" and pass that to machine_init. That makes it pretty straight forward. > And how to deal with the monitor interface > then? Keep it, extend it? Extend it with the same syntax, in the same fashion. > Moreover, how should we express the case of > enabling the boot menu without providing any boot device, > "-boot prompt=on"? Then parsing this will be fun - not impossible, for > sure. But so far I'm looking for a straightforward approach. > I don't know that that syntax is needed. You could force -boot ,prompt=on but I think just explicitly specifying -boot cad,prompt=on is enough. >> Or firmware config since that can be shared with non-x86 targets. >> > > I'm open for the firmware config if you explain to me how state > information is supposed to be transfered from rombios32.c (where the > fw_cfg is evaluated) to some function in rombios.c. Tried this but found > nothing obvious. > Gleb, could you comment here? I'm obviously ignorant of the firmware config code in the BIOS. It seems like the right thing to use but if it's all the current support is in 32-bit code, it may be difficult to use that within the 16-bit code without rewriting it all. Regards, Anthony Liguori > Jan >