From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57889 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAQSC-0001oX-7W for qemu-devel@nongnu.org; Mon, 25 Oct 2010 13:03:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAQQ0-00062a-Dq for qemu-devel@nongnu.org; Mon, 25 Oct 2010 13:01:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAQQ0-00062U-64 for qemu-devel@nongnu.org; Mon, 25 Oct 2010 13:01:08 -0400 Date: Mon, 25 Oct 2010 18:54:25 +0200 From: "Michael S. Tsirkin" Message-ID: <20101025165425.GC19559@redhat.com> References: <4CB48A51.8040508@mail.berlios.de> <4CB8C196.8030403@mail.berlios.de> <4CC5AEFC.3080106@mail.berlios.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC5AEFC.3080106@mail.berlios.de> Subject: [Qemu-devel] Re: Where's gpxe-eepro100-80862449.rom ? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Markus Armbruster , qemu-devel@nongnu.org On Mon, Oct 25, 2010 at 06:23:24PM +0200, Stefan Weil wrote: > Am 25.10.2010 14:11, schrieb Markus Armbruster: > >Stefan Weil writes: > > > >>Am 13.10.2010 09:13, schrieb Markus Armbruster: > >>>Stefan Weil writes: > >[...] > >>>>Do you think there is urgent need for a > >>>>gpxe-eepro100-80862449.rom binary? > >>>> > >>>Well, "-device i82801" complains because it misses this binary. Do we > >>>want to ship that way? > >>> > >> > >>I just sent two patches which create the rom data on load. > >>So -device i82801 no longer complains but gets the boot > >>information from dhcp (tested with i386-softmmu). > >> > >>Your build tree will be made smaller by at least 50 KB :-) > >> > >>Do you think these patches should be added to stable-0.13, too? > > > >If the gain for "-device i82801" is worth the risk, which depends on the > >patch. Have we reached consensus on how to fix it in master? > > > The latest patch version fixes rom data only for the default > roms, so the risk is minimized and full tests are possible. > > There is still no consensus whether we need a new qdev property > (which allows users to have their rom data fixed, too) or not. > > My patch does not prevent adding that new qdev property, > so I suggest applying my patch now and adding the property > later (if it is ever needed). > > Regards > Stefan Fair enough, I guess. -- MST