From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSNtA-0006Tj-1a for qemu-devel@nongnu.org; Thu, 10 May 2012 03:34:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SSNt0-0006bU-6r for qemu-devel@nongnu.org; Thu, 10 May 2012 03:34:15 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:51222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSNsz-0006ap-UD for qemu-devel@nongnu.org; Thu, 10 May 2012 03:34:06 -0400 Received: by pbbro12 with SMTP id ro12so2089923pbb.4 for ; Thu, 10 May 2012 00:34:03 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4FAB6F65.80708@redhat.com> Date: Thu, 10 May 2012 09:33:57 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4FA818F9.90104@msgid.tls.msk.ru> <4FA8AD11.6060905@redhat.com> <4FA8B2FE.60303@msgid.tls.msk.ru> <4FA8C07A.4090505@redhat.com> <4FA95E3A.9080603@msgid.tls.msk.ru> <20120509080242.GN15960@redhat.com> <4FAA96DF.3090006@msgid.tls.msk.ru> In-Reply-To: <4FAA96DF.3090006@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] ahci drive: how to make it non-bootable? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: Gerd Hoffmann , Gleb Natapov , qemu-devel Il 09/05/2012 18:10, Michael Tokarev ha scritto: > > The old hacks which were prematurely removed from qemu-kvm makes the > life easier for the _user_, which is the main target of the software. > I'd love to stop using them but sometimes it is not possible. With > this extboot thing, qemu-kvm dropped ability to boot from SCSI for > example, and it turns out there are quite some users of this interface > exists - despite the fact SCSI is broken, there is a proprietary > bootrom exists etc -- we just broke users setups without providing > viable alternative, which, to my view, is unacceptable. You were using a fork, and this implies some risks of things being broken when upstream decides to do differently (e.g. extboot vs. implementing boot support in SeaBIOS). As far as I know, no feature was removed from upstream QEMU. Paolo