From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqbpN-00072w-CS for qemu-devel@nongnu.org; Thu, 14 Apr 2016 03:36:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqbpI-0004J5-At for qemu-devel@nongnu.org; Thu, 14 Apr 2016 03:36:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqbpI-0004Ix-5g for qemu-devel@nongnu.org; Thu, 14 Apr 2016 03:36:32 -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> Date: Thu, 14 Apr 2016 09:36:28 +0200 In-Reply-To: <20160413205343-mutt-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Wed, 13 Apr 2016 20:53:58 +0300") Message-ID: <87vb3kbq0z.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 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.