From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzPeq-0001Jd-Ow for qemu-devel@nongnu.org; Mon, 01 Jun 2015 09:21:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzPel-0006Vz-4R for qemu-devel@nongnu.org; Mon, 01 Jun 2015 09:21:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzPek-0006V7-V9 for qemu-devel@nongnu.org; Mon, 01 Jun 2015 09:21:31 -0400 Message-ID: <556C5C55.30808@redhat.com> Date: Mon, 01 Jun 2015 15:21:25 +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> <556C417D.4050707@redhat.com> <20150601143447-mutt-send-email-mst@redhat.com> In-Reply-To: <20150601143447-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" Cc: matt.fleming@intel.com, "Gabriel L. Somlo" , qemu-devel@nongnu.org, gsomlo@gmail.com, kraxel@redhat.com, Paolo Bonzini On 06/01/15 14:38, Michael S. Tsirkin wrote: > On Mon, Jun 01, 2015 at 01:26:53PM +0200, Laszlo Ersek wrote: >> 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 > > I'm sorry - I don't understand. It's easy to do the right thing. Just > add the opt prefix. Why insist on user doing the right thing, and punish > violations with failing at random? I'm not insisting, just trying to explain / repeat the thought process (from more than one month ago :)) that lead up to Gabriel's v4. Thanks Laszlo > If it's useful for developers somehow, add a config flag for that. >