All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: berrange@redhat.com, ehabkost@redhat.com,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, pbonzini@redhat.com, eblake@redhat.com
Subject: Re: [RFC PATCH 00/12] QOM/QAPI integration part 1
Date: Tue, 14 Dec 2021 12:52:30 +0100	[thread overview]
Message-ID: <YbiFfnsR009U+Nrd@redhat.com> (raw)
In-Reply-To: <CAFEAcA_MhWPycXs0yZtnHq1BTdYecDHR+xGo21o8ASP=hFSr1g@mail.gmail.com>

Am 14.12.2021 um 11:40 hat Peter Maydell geschrieben:
> On Tue, 14 Dec 2021 at 10:26, Kevin Wolf <kwolf@redhat.com> wrote:
> > Configuration is for creating objects, properties are for runtime after
> > the creation.
> 
> Well, yes and no. In a few places we have some properties which
> are morally speaking configuration stuff, but which are runtime
> settable. This happens because the property needs to be set after
> the device is realized but before the machine is run, and we
> don't have a concept of "settable only during the machine creation
> phase", only of "settable only before realize". (I can't find an
> example of this in the codebase offhand, but I definitely have one
> in a patchset I'm working on -- the code which needs to
> configure the property of the configured object is far removed
> in both location in the codebase and point at which it runs
> from the code which is doing the initialize-and-realize.)

Yes, that's fair, but for the infrastructure it doesn't matter much what
something is "morally speaking". These things use properties at
"runtime" (i.e. after realize) today and will keep using them until we
find a different solution. I have no intention to change anything about
it in the context of QAPIfication. The only liberty I'm taking is
removing setters that can't work after realize.

Kevin



  reply	other threads:[~2021-12-14 11:54 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 17:29 [RFC PATCH 00/12] QOM/QAPI integration part 1 Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 01/12] qapi: Add visit_next_struct_member() Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 02/12] qom: Create object_configure() Kevin Wolf
2021-11-23 15:23   ` Markus Armbruster
2021-12-14  9:52     ` Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 03/12] qom: Make object_configure() public Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 04/12] qom: Add instance_config() to TypeInfo Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 05/12] rng-random: Implement .instance_config Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 06/12] rng-backend: " Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 07/12] qapi: Allow defining QOM classes Kevin Wolf
2021-11-23 10:02   ` Markus Armbruster
2021-12-10 17:53     ` Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 08/12] qapi: Create qom-config:... type for classes Kevin Wolf
2021-11-23 13:00   ` Markus Armbruster
2021-12-10 17:41     ` Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 09/12] qapi/qom: Convert rng-backend/random to class Kevin Wolf
2021-11-23 13:15   ` Markus Armbruster
2021-12-10 17:57     ` Kevin Wolf
2021-11-03 17:30 ` [RFC PATCH 10/12] qapi: Generate QOM config marshalling code Kevin Wolf
2021-11-23 14:16   ` Markus Armbruster
2021-12-10 16:50     ` Kevin Wolf
2021-11-03 17:30 ` [RFC PATCH 11/12] qapi/qom: Add class definition for rng-builtin Kevin Wolf
2021-11-03 17:30 ` [RFC PATCH 12/12] qapi/qom: Add class definition for rng-egd Kevin Wolf
2021-11-03 21:26 ` [RFC PATCH 00/12] QOM/QAPI integration part 1 Paolo Bonzini
2021-11-04  9:07   ` Kevin Wolf
2021-11-04 12:39     ` Paolo Bonzini
2021-11-04 14:26       ` Kevin Wolf
2021-11-04 14:49         ` Paolo Bonzini
2021-11-04 15:51           ` Kevin Wolf
2021-11-04 15:52     ` Damien Hedde
2021-11-05 13:55       ` Kevin Wolf
2021-11-23 16:05 ` Markus Armbruster
2021-12-14 10:23   ` Kevin Wolf
2021-12-14 10:40     ` Peter Maydell
2021-12-14 11:52       ` Kevin Wolf [this message]
2021-12-14 14:45     ` Markus Armbruster
2021-12-14 16:00       ` Kevin Wolf

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=YbiFfnsR009U+Nrd@redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.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.