"Michael S. Tsirkin" <m...@redhat.com> writes:
> 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.
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.
