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
