From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzNs0-0003Ri-3g for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:27:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzNrv-0003vl-1b for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:27:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzNru-0003vh-TN for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:26:58 -0400 Message-ID: <556C417D.4050707@redhat.com> Date: Mon, 01 Jun 2015 13:26:53 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1430320913-20737-1-git-send-email-somlo@cmu.edu> <1430320913-20737-5-git-send-email-somlo@cmu.edu> <20150531181048.GC5268@redhat.com> <556C046B.9070704@redhat.com> <20150601092645-mutt-send-email-mst@redhat.com> <556C1F63.1090605@redhat.com> <20150601121908-mutt-send-email-mst@redhat.com> <556C3757.7080603@redhat.com> <20150601124604-mutt-send-email-mst@redhat.com> In-Reply-To: <20150601124604-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V4 4/4] fw_cfg: insert fw_cfg file blobs via qemu cmdline List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Paolo Bonzini Cc: gsomlo@gmail.com, "Gabriel L. Somlo" , matt.fleming@intel.com, kraxel@redhat.com, qemu-devel@nongnu.org On 06/01/15 12:48, Michael S. Tsirkin wrote: > On Mon, Jun 01, 2015 at 12:43:35PM +0200, Paolo Bonzini wrote: >> >> >> On 01/06/2015 12:23, Michael S. Tsirkin wrote: >>> Still, reserving part of the namespace for QEMU internal use >>> is *not* policy, it's just good engineering. >>> >>> How about we forbid adding files under "etc/" ? >>> >>> That would be enough to avoid conflicts. >> >> I do not understand. What we're doing is free-beer. We can always say >> no. What's your worry? > > Someone writes a tool using a specific path. > We then add same path upstream, script breaks. > >> One usecase of this feature is to avoid recompiling QEMU while playing >> with firmware. If you cannot mimic QEMU's behavior (which is to add >> "etc/" files), the feature is pointless, or at least I totally cannot >> understand its purpose and I'm against merging it. >> >> Paolo > > Confused. Why does it produce the warning then? > > If it's just for playing games, add a configure > switch to enable it, and disable by default. > Don't set traps for users. The site specific feature can be long-term for a given site. It might live across several QEMU upgrades. New version of QEMU introdces a new fw_cfg file, might conflict with user's file from earlier. Unless the user places it under opt/. For that reason we emit a warning, but do not forcefully prevent the user from shooting his foot off. Laszlo