From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzNXU-0005OZ-At for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:05:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzNXQ-00038s-PG for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:05:52 -0400 Received: from mail-yk0-x231.google.com ([2607:f8b0:4002:c07::231]:36305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzNXQ-00038H-65 for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:05:48 -0400 Received: by yked142 with SMTP id d142so42428182yke.3 for ; Mon, 01 Jun 2015 04:05:47 -0700 (PDT) Date: Mon, 1 Jun 2015 07:05:13 -0400 From: "Gabriel L. Somlo" Message-ID: <20150601110512.GA10201@GLSMBP.INI.CMU.EDU> 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> <556C390A.7090706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556C390A.7090706@redhat.com> 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: Paolo Bonzini Cc: matt.fleming@intel.com, "Michael S. Tsirkin" , "Gabriel L. Somlo" , qemu-devel@nongnu.org, kraxel@redhat.com, Laszlo Ersek On Mon, Jun 01, 2015 at 12:50:50PM +0200, Paolo Bonzini wrote: > > Someone writes a tool using a specific path. > > We then add same path upstream, script breaks. > > Who cares. We documented it. > > >> 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. > > > > Confused. Why does it produce the warning then? > > Because someone else asked for it. I cannot answer. :) > > > If it's just for playing games, add a configure > > switch to enable it, and disable by default. > > Don't set traps for users. > > What is for playing games? What is the feature useful for, except for > developers. My interest in this is for its asynchronous, agent-less host->guest communication capability. As such, I would like it to be available at all times, not just in special builds after enabling a build-time switch... As for the (meta)policy aspect (i.e., warn vs. error-out when outside "opt/"), I am happy to go with whatever consensus emerges from this conversation. I get both sides' positions, but don't have enough context to feel strongly either way myself... :) Thanks much, --Gabriel