From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NAOyJ-0000mG-1i for qemu-devel@nongnu.org; Tue, 17 Nov 2009 09:23:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NAOyC-0000iG-EF for qemu-devel@nongnu.org; Tue, 17 Nov 2009 09:23:52 -0500 Received: from [199.232.76.173] (port=50677 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAOyB-0000hi-RV for qemu-devel@nongnu.org; Tue, 17 Nov 2009 09:23:47 -0500 Received: from cantor2.suse.de ([195.135.220.15]:38979 helo=mx2.suse.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NAOyA-00050A-Sd for qemu-devel@nongnu.org; Tue, 17 Nov 2009 09:23:47 -0500 Message-ID: <4B02B1EA.5060000@suse.de> Date: Tue, 17 Nov 2009 15:23:38 +0100 From: Alexander Graf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] extboot reloaded. References: <1258394678-8634-1-git-send-email-kraxel@redhat.com> <200911171236.03478.paul@codesourcery.com> <4B029E9D.3050003@redhat.com> <200911171335.22727.paul@codesourcery.com> In-Reply-To: <200911171335.22727.paul@codesourcery.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: Paul Brook Cc: Kevin O'Connor , qemu-devel@nongnu.org, Gerd Hoffmann Paul Brook wrote: > On Tuesday 17 November 2009, Gerd Hoffmann wrote: > >> On 11/17/09 13:36, Paul Brook wrote: >> >>>>> In fact I'd much prefer to see extboot rewritten to just virtio-block. >>>>> >>>> Hmm, I'd prefer something which is *not* used by the guest OS, so it is >>>> a pure bootloader thing. When using it to boot from scsi you don't want >>>> to have the disk show up twice (as virtio and scsi) in the guest. >>>> >>> You're assuming noone ever writes OS support for extboot... >>> >> Which would be almost as silly as writing OS support for bios-int13 ... >> > > Not entirely. int13 is a software interface, extboot is a hardware interface. > Look at it the other way round: If I already have my low performance boot > device exposed via extboot (on an otherwise diskless client), why should I > have to also expose it via virtio-blk just so that the guest can access it for > installing kernel upgrades. > Because that's not what you'd use it for. That's what -kernel and -initrd are there for. IMHO having a BIOS backdoor is a good thing in general. If anyone wants to destroy their user experience by writing a driver for that in their OS, I'm good with that, but let's not expose things twice _to users_ as the default case. Alex