Re: [Qemu-devel] Dropped CPU feature names and backward compatibility

[Eduardo Habkost]

On Wed, Sep 19, 2018 at 07:09:24PM +0200, Paolo Bonzini wrote:
> On 19/09/2018 18:36, Eduardo Habkost wrote:
> > On Tue, Sep 18, 2018 at 05:35:20PM +0200, Paolo Bonzini wrote:
> >> On 18/09/2018 16:22, Eduardo Habkost wrote:
> >>> On Tue, Sep 18, 2018 at 04:02:54PM +0200, Paolo Bonzini wrote:
> >>>> On 18/09/2018 15:14, Eduardo Habkost wrote:
> >>>>> If it broke something, we should restore the option names and
> >>>>> declare them as deprecated.
> >>>>
> >>>> I think in this particular case it's okay to add them back as no-ops,
> >>>> especially we'd actually want them to be customizable for user-mode
> >>>> emulation.
> >>>
> >>> We can make the flag work on user-mode emulation, but I wouldn't
> >>> like to keep QEMU silent if the option was explicitly set in the
> >>> command-line in system emulation, because it means the user or
> >>> some software component is really confused and trying to do
> >>> something that is never going to work.
> >>
> >> They just want to copy the host flags blindly into the guest.  osxsave
> >> and ospke require some collaboration from the guest OS, but it should be
> >> pretty harmless to have them on the command line, because in the end the
> >> apps _should_ anyway be checking OSPKE.  If somebody is writing such an
> >> app and is puzzled that OSPKE is missing, they should first of all ask
> >> themselves if they have installed the right guest OS.
> > 
> > I wouldn't say that a no-op option that would just confuse
> > apps/users is harmless.  I really don't see any benefit in
> > keeping it.
> 
> But how would it be confusing?  It's perhaps worth warning, but that's it.

If we have a reason to warn users, it qualifies as confusing to
me.

Anyway, this specific case is not a big deal.  But I would say
that our tendency to needlessly sacrifice maintainability for the
sake of compatibility is a big problem in the long run.

-- 
Eduardo