qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 1/4] target-arm: Add CPU property to disable


From: Greg Bellows
Subject: Re: [Qemu-devel] [PATCH v3 1/4] target-arm: Add CPU property to disable AArch64
Date: Tue, 3 Feb 2015 15:45:27 -0600



On Tue, Feb 3, 2015 at 3:21 PM, Christoffer Dall <address@hidden> wrote:
On Tue, Feb 3, 2015 at 10:15 PM, Peter Maydell <address@hidden> wrote:
> On 3 February 2015 at 19:14, Peter Maydell <address@hidden> wrote:
>> On 27 January 2015 at 23:58, Greg Bellows <address@hidden> wrote:
>>>  static void aarch64_cpu_initfn(Object *obj)
>>>  {
>>> +    object_property_add_bool(obj, "aarch64", aarch64_cpu_get_aarch64,
>>> +                             aarch64_cpu_set_aarch64, NULL);
>>> +    object_property_set_description(obj, "aarch64",
>>> +                                    "Set on/off to enable/disable aarch64 "
>>> +                                    "execution state ",
>>> +                                    NULL);
>>>  }
>>
>> This all looks OK code-wise. Still need to think about whether we
>> can manage to end up with a nicer interface to the user than
>> cpuname,-aarch64, though.
>
> [I meant "-cpu cpuname,aarch64=off", hadn't processed that we've
> updated to the new style syntax.]
>
> I had a think about this as I was cycling home, and I (re)convinced
> myself that modelling this as "remove the AArch64 feature flag" is
> the right way to do it, which then just leaves us with "what's the
> best user-facing UI we can manage to expose that?".
>
> Suppose that we had two properties/feature flag switches that do
> the same thing but have inverse sense:
>
>   aarch64=off
>   aarch32-> >
> Would that help, or just be more confusing?
>
that would help, imho.


​Hmmm..., while it is trivial to add the second option I think it would be confusing for users and begs for issues of having both specified.  If we prefer the second name lets go with it otherwise my vote is against having two.  If the behavior of the flag is "remove the AArch64 flag" it seems most natural to stick with what we have as it conveys just that.  The other option seems counter-intuitive.

 
-Christoffer


reply via email to

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