All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"patches@linaro.org" <patches@linaro.org>
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH 2/3] qdev: support properties which don't set a default value
Date: Thu, 13 Jul 2017 20:25:10 +0200	[thread overview]
Message-ID: <87bmootcs9.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA-XrYnnzH58LkyObyJH-eGuEHK-BuQkRjwFbZmMr1oeXQ@mail.gmail.com> (Peter Maydell's message of "Thu, 13 Jul 2017 18:18:06 +0100")

Peter Maydell <peter.maydell@linaro.org> writes:

> On 13 July 2017 at 18:10, Markus Armbruster <armbru@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> On 12 July 2017 at 12:22, Markus Armbruster <armbru@redhat.com> wrote:
>>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>>
>>>>> In some situations it's useful to have a qdev property which doesn't
>>>>> automatically set its default value when qdev_property_add_static is
>>>>> called (for instance when the default value is not constant).
>>>>>
>>>>> Support this by adding a flag to the Property struct indicating
>>>>> whether to set the default value.  This replaces the existing test
>>>>> for whether the PorpertyInfo set_default_value function pointer is
>>>>
>>>> PropertyInfo
>>>>
>>>>> NULL, and we set the .set_default field to true for all those cases
>>>>> of struct Property which use a PropertyInfo with a non-NULL
>>>>> set_default_value, so behaviour remains the same as before.
>>>>>
>>>>> We define two new macros DEFINE_PROP_SIGNED_NODEFAULT and
>>>>> DEFINE_PROP_UNSIGNED_NODEFAULT, to cover the most plausible use cases
>>>>> of wanting to set an integer property with no default value.
>>>>
>>>> Your text makes me wonder what is supposed to set the default value
>>>> then.  Glancing ahead to PATCH 3, it looks like method instance_init()
>>>> is.  Can you think of a scenario where something else sets it?
>>>
>>> OK, proposed extra paragraph for commit message:
>>>
>>> This gives us the semantics of:
>>>  * if .set_default is true and .info->set_default_value is not NULL,
>>>    then .defval is used as the the default value of the property
>>
>> If I read your patch correctly, then this should be "if .set_default is
>> true, then .info->set_default_value() must not be null, and .defval is
>> used ..."
>
> Yes.

Update your comment and commit message accordingly, and you may add
Reviewed-by: Markus Armbruster <armbru@redhat.com>

WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"patches@linaro.org" <patches@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 2/3] qdev: support properties which don't set a default value
Date: Thu, 13 Jul 2017 20:25:10 +0200	[thread overview]
Message-ID: <87bmootcs9.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA-XrYnnzH58LkyObyJH-eGuEHK-BuQkRjwFbZmMr1oeXQ@mail.gmail.com> (Peter Maydell's message of "Thu, 13 Jul 2017 18:18:06 +0100")

Peter Maydell <peter.maydell@linaro.org> writes:

> On 13 July 2017 at 18:10, Markus Armbruster <armbru@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> On 12 July 2017 at 12:22, Markus Armbruster <armbru@redhat.com> wrote:
>>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>>
>>>>> In some situations it's useful to have a qdev property which doesn't
>>>>> automatically set its default value when qdev_property_add_static is
>>>>> called (for instance when the default value is not constant).
>>>>>
>>>>> Support this by adding a flag to the Property struct indicating
>>>>> whether to set the default value.  This replaces the existing test
>>>>> for whether the PorpertyInfo set_default_value function pointer is
>>>>
>>>> PropertyInfo
>>>>
>>>>> NULL, and we set the .set_default field to true for all those cases
>>>>> of struct Property which use a PropertyInfo with a non-NULL
>>>>> set_default_value, so behaviour remains the same as before.
>>>>>
>>>>> We define two new macros DEFINE_PROP_SIGNED_NODEFAULT and
>>>>> DEFINE_PROP_UNSIGNED_NODEFAULT, to cover the most plausible use cases
>>>>> of wanting to set an integer property with no default value.
>>>>
>>>> Your text makes me wonder what is supposed to set the default value
>>>> then.  Glancing ahead to PATCH 3, it looks like method instance_init()
>>>> is.  Can you think of a scenario where something else sets it?
>>>
>>> OK, proposed extra paragraph for commit message:
>>>
>>> This gives us the semantics of:
>>>  * if .set_default is true and .info->set_default_value is not NULL,
>>>    then .defval is used as the the default value of the property
>>
>> If I read your patch correctly, then this should be "if .set_default is
>> true, then .info->set_default_value() must not be null, and .defval is
>> used ..."
>
> Yes.

Update your comment and commit message accordingly, and you may add
Reviewed-by: Markus Armbruster <armbru@redhat.com>

  reply	other threads:[~2017-07-13 18:25 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-11 15:53 [Qemu-arm] [PATCH 0/3] Allow int props with no default, use them in ARM Peter Maydell
2017-07-11 15:53 ` [Qemu-devel] " Peter Maydell
2017-07-11 15:53 ` [Qemu-arm] [PATCH 1/3] qdev-properties.h: Explicitly set the default value for arraylen properties Peter Maydell
2017-07-11 15:53   ` [Qemu-devel] " Peter Maydell
2017-07-11 16:46   ` Marc-André Lureau
2017-07-11 16:46     ` Marc-André Lureau
2017-07-13 14:11   ` [Qemu-arm] " Markus Armbruster
2017-07-13 14:11     ` Markus Armbruster
2017-07-13 14:26     ` [Qemu-arm] " Peter Maydell
2017-07-13 14:26       ` Peter Maydell
2017-07-13 16:21       ` [Qemu-arm] " Markus Armbruster
2017-07-13 16:21         ` Markus Armbruster
2017-07-11 15:53 ` [Qemu-arm] [PATCH 2/3] qdev: support properties which don't set a default value Peter Maydell
2017-07-11 15:53   ` [Qemu-devel] " Peter Maydell
2017-07-11 17:15   ` Marc-André Lureau
2017-07-11 17:15     ` Marc-André Lureau
2017-07-11 17:25     ` [Qemu-arm] " Peter Maydell
2017-07-11 17:25       ` [Qemu-devel] " Peter Maydell
2017-07-12 11:22   ` [Qemu-arm] " Markus Armbruster
2017-07-12 11:22     ` Markus Armbruster
2017-07-12 12:27     ` Peter Maydell
2017-07-12 12:27       ` Peter Maydell
2017-07-13 15:38     ` Peter Maydell
2017-07-13 15:38       ` Peter Maydell
2017-07-13 17:10       ` [Qemu-arm] " Markus Armbruster
2017-07-13 17:10         ` Markus Armbruster
2017-07-13 17:18         ` Peter Maydell
2017-07-13 18:25           ` Markus Armbruster [this message]
2017-07-13 18:25             ` Markus Armbruster
2017-07-11 15:53 ` [Qemu-arm] [PATCH 3/3] target/arm: Make Cortex-M3 and M4 default to 8 PMSA regions Peter Maydell
2017-07-11 15:53   ` [Qemu-devel] " Peter Maydell
2017-07-11 17:18   ` Marc-André Lureau
2017-07-11 17:18     ` Marc-André Lureau
2017-07-11 17:27     ` [Qemu-arm] " Peter Maydell
2017-07-11 17:27       ` [Qemu-devel] " Peter Maydell
2017-07-11 17:30       ` Marc-André Lureau
2017-07-11 17:30         ` Marc-André Lureau

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=87bmootcs9.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.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.