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

[Markus Armbruster]

"Michael S. Tsirkin" <address@hidden> writes:

> 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.

This is what's in 2.4:

    NOTE: Users *SHOULD* choose item names beginning with the prefix "opt/"
    when using the "-fw_cfg" command line option, to avoid conflicting with
    item names used internally by QEMU. For instance:

        -fw_cfg name=opt/my_item_name,file=./my_blob.bin

Interpreting the "should" as "or else we'll break your usage without
prior notice" is a bit of a stretch.

As a matter of principle, I'm unwilling to renege on backward
compatibility that way without a convincing reason.  I find your attempt
at protecting users of an arcane -fw_cfg from (some of) their own
foolishness insufficiently convincing.