On Thu, Apr 14, 2016 at 09:36:28AM +0200, Markus Armbruster wrote: > "Michael S. Tsirkin" <m...@redhat.com> writes: > > > On Wed, Apr 13, 2016 at 06:17:29PM +0200, Markus Armbruster wrote: > >> "Michael S. Tsirkin" <m...@redhat.com> 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
