From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqfS3-0007M3-Fn for qemu-devel@nongnu.org; Thu, 14 Apr 2016 07:28:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqfS0-0003YG-9e for qemu-devel@nongnu.org; Thu, 14 Apr 2016 07:28:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqfS0-0003Y6-2C for qemu-devel@nongnu.org; Thu, 14 Apr 2016 07:28:44 -0400 From: Markus Armbruster References: <1460102035-15972-1-git-send-email-mst@redhat.com> <87twjcvz7o.fsf@dusky.pond.sub.org> <20160409200141-mutt-send-email-mst@redhat.com> <8760voo18x.fsf@dusky.pond.sub.org> <20160411142509-mutt-send-email-mst@redhat.com> <8760vlq3yg.fsf@dusky.pond.sub.org> <20160413135342-mutt-send-email-mst@redhat.com> <87h9f5iiue.fsf@dusky.pond.sub.org> <20160413205343-mutt-send-email-mst@redhat.com> <87vb3kbq0z.fsf@dusky.pond.sub.org> <20160414110932-mutt-send-email-mst@redhat.com> Date: Thu, 14 Apr 2016 13:28:40 +0200 In-Reply-To: <20160414110932-mutt-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Thu, 14 Apr 2016 11:10:32 +0300") Message-ID: <871t68a0pj.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , "Gabriel L . Somlo" , Laszlo Ersek , qemu-devel@nongnu.org, Gerd Hoffmann "Michael S. Tsirkin" writes: > On Thu, Apr 14, 2016 at 09:36:28AM +0200, Markus Armbruster wrote: >> "Michael S. Tsirkin" writes: >> >> > On Wed, Apr 13, 2016 at 06:17:29PM +0200, Markus Armbruster wrote: >> >> "Michael S. Tsirkin" writes: >> >> >> >> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote: >> >> >> I have a hard time coming up with realistic unclean breakage. >> >> > >> >> > The issue is that Linux is now exposing fw cfg to userspace. >> >> > So it's use is about to expand significantly. >> >> > >> >> > This is what I am trying to prevent: >> >> > - in 2016, users build a guest using a path XXX outside opt. >> >> > there's a warning on host, but it is not noticed. >> >> >> >> Amend: >> >> >> >> The guest treats path XXX as optional. >> >> >> >> > - in 2020, qemu starts using path XXX for internal purposes. >> >> > - using guest from 2016 now breaks uncleanly on this new qemu >> >> >> >> Amend: >> >> >> >> when we're not specifying the optional path XXX with -fw_cfg. >> >> >> >> > since guest thinks it's talking to the external tool. >> >> >> >> Okay, that's a much more plausible scenario. The question remains >> >> whether preventing it justifies the compat break and the additional >> >> interface complexity. >> > >> > there is no break as long as people follow the rules. >> >> -fw_cfg exists since 2.4. You can't slap rules onto it in 2.6, and >> immediately claim compatibility matters only for usage following these >> rules. > > The rule about "opt/" was always there, right? So we can at least > start enforcing that. This is what's in 2.4: NOTE: Users *SHOULD* choose item names beginning with the prefix "opt/" when using the "-fw_cfg" command line option, to avoid conflicting with item names used internally by QEMU. For instance: -fw_cfg name=opt/my_item_name,file=./my_blob.bin Interpreting the "should" as "or else we'll break your usage without prior notice" is a bit of a stretch. As a matter of principle, I'm unwilling to renege on backward compatibility that way without a convincing reason. I find your attempt at protecting users of an arcane -fw_cfg from (some of) their own foolishness insufficiently convincing.