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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.