From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIlHr-0008RV-1L for qemu-devel@nongnu.org; Tue, 03 Feb 2015 16:45:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIlHl-0002KQ-NM for qemu-devel@nongnu.org; Tue, 03 Feb 2015 16:45:34 -0500 Received: from mail-qa0-f42.google.com ([209.85.216.42]:58181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIlHk-0002K5-Tv for qemu-devel@nongnu.org; Tue, 03 Feb 2015 16:45:29 -0500 Received: by mail-qa0-f42.google.com with SMTP id dc16so35898115qab.1 for ; Tue, 03 Feb 2015 13:45:28 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1422403117-16921-1-git-send-email-greg.bellows@linaro.org> <1422403117-16921-2-git-send-email-greg.bellows@linaro.org> Date: Tue, 3 Feb 2015 15:45:27 -0600 Message-ID: From: Greg Bellows Content-Type: multipart/alternative; boundary=001a11c2b31c3a28fb050e35fd9e Subject: Re: [Qemu-devel] [PATCH v3 1/4] target-arm: Add CPU property to disable AArch64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoffer Dall Cc: Peter Maydell , =?UTF-8?B?QWxleCBCZW5uw6ll?= , QEMU Developers --001a11c2b31c3a28fb050e35fd9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 3, 2015 at 3:21 PM, Christoffer Dall < christoffer.dall@linaro.org> wrote: > On Tue, Feb 3, 2015 at 10:15 PM, Peter Maydell > wrote: > > On 3 February 2015 at 19:14, Peter Maydell > wrote: > >> On 27 January 2015 at 23:58, Greg Bellows > 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=3Doff", 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=3Doff > > aarch32-only=3Don > > > > Would that help, or just be more confusing? > > > that would help, imho. > > =E2=80=8BHmmm..., while it is trivial to add the second option I think it w= ould 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 > --001a11c2b31c3a28fb050e35fd9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 3, 2015 at 3:21 PM, Christoffer Dall <c= hristoffer.dall@linaro.org> wrote:
On Tue, Feb 3, 2015 at 10:1= 5 PM, Peter Maydell <peter.m= aydell@linaro.org> wrote:
> On 3 February 2015 at 19:14, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 27 January 2015 at 23:58, Greg Bellows <greg.bellows@linaro.org> wrote:
>>>=C2=A0 static void aarch64_cpu_initfn(Object *obj)
>>>=C2=A0 {
>>> +=C2=A0 =C2=A0 object_property_add_bool(obj, "aarch64&quo= t;, aarch64_cpu_get_aarch64,
>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aarch64_cpu_set_aarch64, NULL)= ;
>>> +=C2=A0 =C2=A0 object_property_set_description(obj, "aarc= h64",
>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Se= t on/off to enable/disable aarch64 "
>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ex= ecution state ",
>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NULL); >>>=C2=A0 }
>>
>> This all looks OK code-wise. Still need to think about whether we<= br> >> can manage to end up with a nicer interface to the user than
>> cpuname,-aarch64, though.
>
> [I meant "-cpu cpuname,aarch64=3Doff", 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&qu= ot; 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:
>
>=C2=A0 =C2=A0aarch64=3Doff
>=C2=A0 =C2=A0aarch32-only=3Don
>
> Would that help, or just be more confusing?
>
that would help, imho.


=E2=80=8BHmmm..., while it is trivial to add the = second option I think it would be confusing for users and begs for issues o= f having both specified.=C2=A0 If we prefer the second name lets go with it= otherwise my vote is against having two.=C2=A0 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.=C2=A0 The other option seems counter= -intuitive.

=C2=A0
= -Christoffer

--001a11c2b31c3a28fb050e35fd9e--