From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3bax-0006ko-RC for qemu-devel@nongnu.org; Wed, 15 Jan 2014 20:18:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3bas-0005py-UE for qemu-devel@nongnu.org; Wed, 15 Jan 2014 20:18:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3bas-0005pu-Ln for qemu-devel@nongnu.org; Wed, 15 Jan 2014 20:18:02 -0500 Date: Thu, 16 Jan 2014 09:16:50 +0800 From: Fam Zheng Message-ID: <20140116011650.GD2073@T430.nay.redhat.com> References: <1389775713-996-1-git-send-email-famz@redhat.com> <52D696F6.5020307@redhat.com> <52D69CDD.6000809@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v16 0/9] Shared library module support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Kevin Wolf , Stefan Hajnoczi , Michael Tokarev , QEMU Developers , Alex Bligh , Paolo Bonzini , Miroslav Rezanina , =?iso-8859-1?Q?Llu=EDs?= Vilanova , Richard Henderson On Wed, 01/15 14:40, Peter Maydell wrote: > On 15 January 2014 14:36, Paolo Bonzini wrote: > > Il 15/01/2014 15:20, Peter Maydell ha scritto: > >>> > > >>> > On RHEL6 I tried "qemu-system-x86_64 -cdrom > >>> > http://boot.ipxe.org/ipxe.iso" and it worked, but it failed on Fedora. > >>> > I don't know if it's a QEMU or curl bug. > >> Doesn't work on MacOSX either: it says > >> qemu-system-x86_64: -cdrom http://boot.ipxe.org/ipxe.iso: could not > >> open disk image http://boot.ipxe.org/ipxe.iso: Unknown protocol > > > > Had you installed QEMU before starting it? Fam, I think you need a way > > to override CONFIG_MODDIR (even an environment variable could do). > > No, I pretty much never install QEMU. I always run it out of a build > directory. Module loading should IMHO work with similar semantics > to the data dir we use for BIOS file loading: one of the places checked > is relative to the executable path. > > Maybe we should also have better error messages for "I tried > to load a module and this error is because I couldn't find one", > so the user might be prompted to install the modules package his > distro provides or investigate config if it's self-built, or whatever... > Sounds good to me. Will add a message. Fam