All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH qemu] qom: Document qom/device-list-properties implementation specific
Date: Wed, 02 May 2018 14:36:10 +0200	[thread overview]
Message-ID: <8760462q11.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <2fc4e700-9222-8785-efc3-f2749be298ab@redhat.com> (Paolo Bonzini's message of "Wed, 2 May 2018 11:47:45 +0200")

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 02/05/2018 11:38, Markus Armbruster wrote:
>>>>> It probably is not unless someone adds properties in realize() callback,
>>>> Now work that into the doc comment, please :)
>>> Are there any examples?
>> There must be examples where instances of the same type have different
>> properties, or else our design decision to create properties dynamically
>> was inane.
>
> Buses for example create properties at runtime to link a parent to its
> children.  These properties are created when a child device appears;
> this is different from creating properties in or the realize() callback,
> or upon setting other properties.
>
> The purpose of this command is to tell people/tools what they can pass
> to -device/-object/device_add/object_add, so the real question is
> whether there are cases where it falls short of that purpose.
>
> If not,

Do we have to be certain?  Or would "we don't think so" be enough?

>         maybe the wording for the .json file could be something like:
>
>   Objects can create properties at runtime, for example to describe
>   links between different devices and/or objects.  These properties
>   are not included in the output of this command.

Not bad.

In theory, objects can also create properties in response to non-default
configuration, and these would also not be included.  Objects could even
create a property with the same name, but different type or description.
Arguably capital-letter Bad Ideas, but nothing prevents such misuse.

Since I'm in a generous mood, I'd rate the thing at Rusty API level 4
"Follow common convention and you'll get it right."

https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html

If dynamic properties are really just for internal use, as you seem to
suggest in Message-ID:
<c1d40d88-1c80-2bbd-c28c-613b7fe8d45e@redhat.com>, then we should've had
the common sense to unambiguously separate them from the user-facing
properties.  Can we still do that?

  reply	other threads:[~2018-05-02 12:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-03  0:25 [Qemu-devel] [PATCH qemu v4 0/2] qmp: Add qom-list-properties to list QOM object properties Alexey Kardashevskiy
2018-03-03  0:25 ` [Qemu-devel] [PATCH qemu v4 1/2] qmp: Merge ObjectPropertyInfo and DevicePropertyInfo Alexey Kardashevskiy
2018-04-18 16:35   ` Eric Blake
2018-04-30 10:04     ` Paolo Bonzini
2018-03-03  0:25 ` [Qemu-devel] [PATCH qemu v4 2/2] qmp: Add qom-list-properties to list QOM object properties Alexey Kardashevskiy
2018-04-13 14:16   ` Markus Armbruster
2018-04-30  6:52     ` [Qemu-devel] [PATCH qemu] qom: Document qom/device-list-properties implementation specific Alexey Kardashevskiy
2018-04-30  6:56       ` no-reply
2018-04-30  7:07         ` Alexey Kardashevskiy
2018-04-30  6:58       ` no-reply
2018-04-30  7:00       ` no-reply
2018-04-30  9:39       ` Paolo Bonzini
2018-05-02  1:26         ` Alexey Kardashevskiy
2018-05-02  6:34           ` Markus Armbruster
2018-05-02  9:11             ` Paolo Bonzini
2018-05-02  9:33               ` Alexey Kardashevskiy
2018-05-02  9:50                 ` Paolo Bonzini
2018-05-03  6:22                   ` Alexey Kardashevskiy
2018-05-03 10:54                     ` Paolo Bonzini
2018-05-02  9:38               ` Markus Armbruster
2018-05-02  9:47                 ` Paolo Bonzini
2018-05-02 12:36                   ` Markus Armbruster [this message]
2018-05-02 12:42                     ` Paolo Bonzini
2018-05-02 13:31                       ` Markus Armbruster
2018-05-02 13:32                         ` Paolo Bonzini
2018-05-01 13:01       ` Eric Blake
2018-05-02  1:33         ` Alexey Kardashevskiy

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=8760462q11.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=pbonzini@redhat.com \
    --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.