qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation
Date: Thu, 14 Apr 2016 11:10:32 +0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]