From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqOzN-0005tK-Ot for qemu-devel@nongnu.org; Wed, 13 Apr 2016 13:54:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqOzJ-000682-Km for qemu-devel@nongnu.org; Wed, 13 Apr 2016 13:54:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqOzJ-00067u-Fy for qemu-devel@nongnu.org; Wed, 13 Apr 2016 13:54:01 -0400 Date: Wed, 13 Apr 2016 20:53:58 +0300 From: "Michael S. Tsirkin" Message-ID: <20160413205343-mutt-send-email-mst@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h9f5iiue.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Paolo Bonzini , "Gabriel L . Somlo" , Laszlo Ersek , qemu-devel@nongnu.org, Gerd Hoffmann 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.