From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqcMJ-0006mR-Jv for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:10:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqcMF-0005ZI-Ii for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:10:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45109) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqcMF-0005ZE-DY for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:10:35 -0400 Date: Thu, 14 Apr 2016 11:10:32 +0300 From: "Michael S. Tsirkin" Message-ID: <20160414110932-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> <20160413205343-mutt-send-email-mst@redhat.com> <87vb3kbq0z.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vb3kbq0z.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 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. -- MST