From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCwjJ-00029m-A4 for qemu-devel@nongnu.org; Wed, 17 Dec 2008 08:46:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCwjH-000293-Kh for qemu-devel@nongnu.org; Wed, 17 Dec 2008 08:46:24 -0500 Received: from [199.232.76.173] (port=47731 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCwjH-00028x-Gq for qemu-devel@nongnu.org; Wed, 17 Dec 2008 08:46:23 -0500 Received: from david.siemens.de ([192.35.17.14]:19496) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LCwjH-0008Qb-1h for qemu-devel@nongnu.org; Wed, 17 Dec 2008 08:46:23 -0500 Message-ID: <49490282.3080800@siemens.com> Date: Wed, 17 Dec 2008 14:45:38 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support References: <1229440810-12394-1-git-send-email-Laurent.Vivier@bull.net> <49480F6D.2010302@codemonkey.ws> <20081217110319.GD13455@redhat.com> <200812171318.58650.paul@codesourcery.com> In-Reply-To: <200812171318.58650.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 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: Paul Brook Cc: kvm developers , qemu-devel@nongnu.org, Blue Swirl , bochs developers Paul Brook wrote: >>> Modern BIOSes have splash screens. I don't see why our BIOS shouldn't >>> have one too. >> Crap PC BIOSes have splash screens because they're horribly slow >> and otherwise printing lots of irrelevant scary junk at users. The >> best BIOS 'splash' screen is one which never appears unless there >> is a boot failure, and gets control to the OS as quickly as possible. >> IMHO a better goal is reducing the time until the OS / bootloader is >> able to take over all management of the display. > > I agree. The qemu bios init process takes almost no time. > > The only reason it takes a noticeable amount of time is that we have a > deliberate delay in there to allow the user to access the boot menu. > I'm not convinced this menu is actually very useful in practice, It's > something that should probably be delegated to your management utility and/or > be optional. Yes, please. I hate this artificial delay, specifically as I have to do a lot of short boot tests where this contributes noticeably to their execution time. But, as usual, it didn't hurt enough to make me hack a patch yet. I'm willing to do this if we can agree on how it should be done. Jan -- Siemens AG, Corporate Technology, CT SE 26 Corporate Competence Center Embedded Linux