From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
Antony Pavlov <antonynpavlov@gmail.com>,
Mark Langsdorf <mark.langsdorf@calxeda.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH arm-devs v3 1/9] qom/object: Make uintXX added properties writable
Date: Sun, 15 Dec 2013 20:07:31 +0200 [thread overview]
Message-ID: <20131215180730.GA12055@redhat.com> (raw)
In-Reply-To: <52ADED60.2090303@suse.de>
On Sun, Dec 15, 2013 at 06:56:48PM +0100, Andreas Färber wrote:
> Am 15.12.2013 06:59, schrieb Peter Crosthwaite:
> > Ping!
> >
> > I'm trying to figure out what way I want to go here.
> >
> > On Sat, Dec 7, 2013 at 12:49 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> On 3 December 2013 13:19, Andreas Färber <afaerber@suse.de> wrote:
> >>> Am 03.12.2013 07:59, schrieb Peter Crosthwaite:
> >>>> Currently the uintXX property adders make a read only property. This
> >>>> is not useful for devices that want to create board (or container)
> >>>> configurable dynamic device properties. Fix by trivially adding property
> >>>> setters to object_property_add_uintXX.
> >>>>
> >>>> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> >>>> ---
> >>>> changed since v2:
> >>>> msg typo: "trivially"
> >>>
> >>> Not sure if I've asked already, but these functions were added by mst
> >>> (so let's CC him) for accessing read-only constants in ACPI code. Your
> >>> change seems to make them writable - can anything go wrong when the
> >>> setters are used via QMP?
> >
> > Maybe. But that should be an ACPI problem.
>
> No, it means that if you change it you need to touch ACPI code as well -
> or to design your change in a way that avoids exactly that, e.g. by
> adding a new API reusing the existing getters rather than changing the
> semantics of the existing API used by ACPI.
>
> > It seems that the semantics
> > of these qom/object.c APIs has been set by the lead example. Maybe
> > just an extra arg for RD/WR flags would do the trick however?
>
> If you can get the extra arg passed through as opaque then sure, that
> would be an option, passing false for all existing users.
>
> >>> I fear we may need two separate sets of
> >>> functions, one read-only, one read-write.
> >>
> >> We don't want a generically writable property for CBAR either, though:
> >> we want the standard qdev property semantics of "writable until
> >> realize, readonly thereafter".
> >>
> >
> > Well, with a bit of replumbing I spose we could make qdev property
> > adder framework accessible to post_init to have access to
> > setter/getter fns that implement these semantics.
>
> Sorry, I don't get how that is related to post_init? All that's needed
> is a check of DeviceState::realized in your setter and to error_setg()
> out if true.
>
> Regards,
> Andreas
I think ability to add read only properties is reasonable though.
ACPI wants these since we calculate the value ourselves.
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-12-15 18:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 6:58 [Qemu-devel] [PATCH arm-devs v3 0/9] Fix Support for ARM A9 CBAR Peter Crosthwaite
2013-12-03 6:59 ` [Qemu-devel] [PATCH arm-devs v3 1/9] qom/object: Make uintXX added properties writable Peter Crosthwaite
2013-12-03 13:19 ` Andreas Färber
2013-12-06 14:49 ` Peter Maydell
2013-12-15 5:59 ` Peter Crosthwaite
2013-12-15 17:56 ` Andreas Färber
2013-12-15 18:07 ` Michael S. Tsirkin [this message]
2013-12-16 2:39 ` Peter Crosthwaite
2013-12-16 2:37 ` Peter Crosthwaite
2013-12-15 10:23 ` Michael S. Tsirkin
2013-12-03 13:26 ` Andreas Färber
2013-12-03 7:00 ` [Qemu-devel] [PATCH arm-devs v3 2/9] target-arm/helper.c: Allow cp15.c15 dummy override Peter Crosthwaite
2013-12-06 14:36 ` Peter Maydell
2013-12-03 7:00 ` [Qemu-devel] [PATCH arm-devs v3 3/9] target-arm: Define and use ARM_FEATURE_CBAR Peter Crosthwaite
2013-12-06 14:12 ` Peter Maydell
2013-12-11 0:57 ` Peter Crosthwaite
2013-12-03 7:01 ` [Qemu-devel] [PATCH arm-devs v3 4/9] target-arm/cpu: Convert reset CBAR to a property Peter Crosthwaite
2013-12-06 14:41 ` Peter Maydell
2013-12-11 1:03 ` Peter Crosthwaite
2013-12-16 1:32 ` Peter Crosthwaite
2013-12-03 7:01 ` [Qemu-devel] [PATCH arm-devs v3 5/9] arm/highbank: Use object_new() rather than cpu_arm_init() Peter Crosthwaite
2013-12-06 14:42 ` Peter Maydell
2013-12-03 7:02 ` [Qemu-devel] [PATCH arm-devs v3 6/9] arm/highbank: Fix CBAR initialisation Peter Crosthwaite
2013-12-06 14:43 ` Peter Maydell
2013-12-03 7:02 ` [Qemu-devel] [PATCH arm-devs v3 7/9] arm/xilinx_zynq: Use object_new() rather than cpu_arm_init() Peter Crosthwaite
2013-12-06 14:43 ` Peter Maydell
2013-12-03 7:03 ` [Qemu-devel] [PATCH arm-devs v3 8/9] arm/xilinx_zynq: Implement CBAR initialisation Peter Crosthwaite
2013-12-06 14:44 ` Peter Maydell
2013-12-03 7:04 ` [Qemu-devel] [PATCH arm-devs v3 9/9] arm/highbank.c: Fix MPCore periphbase name Peter Crosthwaite
2013-12-06 14:47 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131215180730.GA12055@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=antonynpavlov@gmail.com \
--cc=mark.langsdorf@calxeda.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).