From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MuDNT-0001X8-Vu for qemu-devel@nongnu.org; Sat, 03 Oct 2009 18:47:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MuDNP-0001Tu-7r for qemu-devel@nongnu.org; Sat, 03 Oct 2009 18:46:59 -0400 Received: from [199.232.76.173] (port=53342 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MuDNO-0001Tk-Ve for qemu-devel@nongnu.org; Sat, 03 Oct 2009 18:46:55 -0400 Received: from ra.coresystems.de ([80.81.252.129]:54610) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MuDNN-0005OG-V1 for qemu-devel@nongnu.org; Sat, 03 Oct 2009 18:46:54 -0400 Message-ID: <4AC7D444.9050007@coresystems.de> Date: Sun, 04 Oct 2009 00:46:28 +0200 From: Stefan Reinauer MIME-Version: 1.0 Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0 References: <4AC4A487.1050003@us.ibm.com> <2a50f7880910011741k65ac8dfbq2fc8c9f58f5fa8d9@mail.gmail.com> <4AC60037.6000001@codemonkey.ws> <2a50f7880910020958g3fe5eadehe5e5094c05b218d9@mail.gmail.com> <4AC64A5C.6010003@gmx.net> <4AC64C32.4020509@codemonkey.ws> <4AC67326.6080603@gmx.net> <20091003150803.GF17326@redhat.com> <20091003173252.1061.qmail@stuge.se> <13426df10910031040y5029dc31m8c6ca4a4bac098a6@mail.gmail.com> <2a50f7880910031513u713f7d52xc95847e9b248964b@mail.gmail.com> In-Reply-To: <2a50f7880910031513u713f7d52xc95847e9b248964b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: Anthony Liguori , Gleb Natapov , Coreboot , Carl-Daniel Hailfinger , qemu-devel@nongnu.org, ron minnich Jordan Justen wrote: > I'm not going to take a side on this matter. But, I think what will > be more important is what is used in the majority of OS's and systems. > This is why we still put the 16-bit legacy BIOS as the #1 priority > after ~30 years. But, like I mention, I think there are signs that > this may shift towards UEFI at some point. > Looking at today's OSes, the BIOS "interface" is basically completely unused except for loading the OS kernel. For future generations of firmware and computers and virtual machines it might make sense to optimize with that situation in mind. The industry we're working in does not see UEFI can cope with the problems firmware has today, unfortunately. After seeing EFI fail so badly with the Itanium it would certainly be nice to see if something can evolve from it in a decade, or two. We're watching excitedly. All the best, Stefan