From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Alistair Francis <alistair.francis@xilinx.com>,
QEMU Trivial <qemu-trivial@nongnu.org>,
Thomas Huth <thuth@redhat.com>,
"qemu-devel\@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] hw/core/or-irq: Mark the device with cannot_instantiate_with_device_add_yet
Date: Fri, 27 Jan 2017 18:18:01 +0100 [thread overview]
Message-ID: <87wpdga0c6.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA-fSMkEVh3DOAh0d-JV=SPF6JqfT0SQ4OjwPbss-Jan_Q@mail.gmail.com> (Peter Maydell's message of "Fri, 27 Jan 2017 16:52:59 +0000")
Peter Maydell <peter.maydell@linaro.org> writes:
> On 27 January 2017 at 16:40, Alistair Francis
> <alistair.francis@xilinx.com> wrote:
>> On Fri, Jan 27, 2017 at 6:51 AM, Thomas Huth <thuth@redhat.com> wrote:
>>> The "or-irq" device is just used internally. It's strange to
>>> see this device showing up in the "-device ?" help text. Let's mark it
>>> with cannot_instantiate_with_device_add_yet to hide it from the users.
>>
>> I agree that it is strange to be showing up to users, but is this
>> really the best way to do this?
>>
>> I thought we were trying to get rid of
>> cannot_instantiate_with_device_add_yet. Would it maybe be better to
>> have an internal filed that sets this device as internal?
>
> Yes, I agree; the reason for cannot_instantiate_with_device_add_yet
> being such a long and ugly name is so it's easy to grep for
> things we in theory might want to fix some day. "We'd rather
> this didn't show up in help" is a different question.
>
> (Like a lot of devices, it's pretty useless via -device, though,
> because we have no way to wire up qemu_irq lines on the command
> line.)
And that's precisely why it needs cannot_instantiate_with_device_add_yet
set. Like any device that needs code to wire it up.
The commit message should state that. There's no need to argue whether
we want to hide it from users.
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>> hw/core/or-irq.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/hw/core/or-irq.c b/hw/core/or-irq.c
>>> index 1ac090d..2487fa3 100644
>>> --- a/hw/core/or-irq.c
>>> +++ b/hw/core/or-irq.c
>>> @@ -89,6 +89,9 @@ static void or_irq_class_init(ObjectClass *klass, void *data)
>>> dc->props = or_irq_properties;
>>> dc->realize = or_irq_realize;
>>> dc->vmsd = &vmstate_or_irq;
>>> +
>>> + /* It's just used internally, and should not be exposed to users */
Make that
/* Reason: needs to be wired up, e.g. by stm32f205_soc_realize() */
>>> + dc->cannot_instantiate_with_device_add_yet = true;
>>> }
>>>
>>> static const TypeInfo or_irq_type_info = {
With that and a rephrased commit message
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: Alistair Francis <alistair.francis@xilinx.com>,
QEMU Trivial <qemu-trivial@nongnu.org>,
Thomas Huth <thuth@redhat.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] hw/core/or-irq: Mark the device with cannot_instantiate_with_device_add_yet
Date: Fri, 27 Jan 2017 18:18:01 +0100 [thread overview]
Message-ID: <87wpdga0c6.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA-fSMkEVh3DOAh0d-JV=SPF6JqfT0SQ4OjwPbss-Jan_Q@mail.gmail.com> (Peter Maydell's message of "Fri, 27 Jan 2017 16:52:59 +0000")
Peter Maydell <peter.maydell@linaro.org> writes:
> On 27 January 2017 at 16:40, Alistair Francis
> <alistair.francis@xilinx.com> wrote:
>> On Fri, Jan 27, 2017 at 6:51 AM, Thomas Huth <thuth@redhat.com> wrote:
>>> The "or-irq" device is just used internally. It's strange to
>>> see this device showing up in the "-device ?" help text. Let's mark it
>>> with cannot_instantiate_with_device_add_yet to hide it from the users.
>>
>> I agree that it is strange to be showing up to users, but is this
>> really the best way to do this?
>>
>> I thought we were trying to get rid of
>> cannot_instantiate_with_device_add_yet. Would it maybe be better to
>> have an internal filed that sets this device as internal?
>
> Yes, I agree; the reason for cannot_instantiate_with_device_add_yet
> being such a long and ugly name is so it's easy to grep for
> things we in theory might want to fix some day. "We'd rather
> this didn't show up in help" is a different question.
>
> (Like a lot of devices, it's pretty useless via -device, though,
> because we have no way to wire up qemu_irq lines on the command
> line.)
And that's precisely why it needs cannot_instantiate_with_device_add_yet
set. Like any device that needs code to wire it up.
The commit message should state that. There's no need to argue whether
we want to hide it from users.
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>> hw/core/or-irq.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/hw/core/or-irq.c b/hw/core/or-irq.c
>>> index 1ac090d..2487fa3 100644
>>> --- a/hw/core/or-irq.c
>>> +++ b/hw/core/or-irq.c
>>> @@ -89,6 +89,9 @@ static void or_irq_class_init(ObjectClass *klass, void *data)
>>> dc->props = or_irq_properties;
>>> dc->realize = or_irq_realize;
>>> dc->vmsd = &vmstate_or_irq;
>>> +
>>> + /* It's just used internally, and should not be exposed to users */
Make that
/* Reason: needs to be wired up, e.g. by stm32f205_soc_realize() */
>>> + dc->cannot_instantiate_with_device_add_yet = true;
>>> }
>>>
>>> static const TypeInfo or_irq_type_info = {
With that and a rephrased commit message
Reviewed-by: Markus Armbruster <armbru@redhat.com>
next prev parent reply other threads:[~2017-01-27 17:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 14:51 [Qemu-trivial] [PATCH] hw/core/or-irq: Mark the device with cannot_instantiate_with_device_add_yet Thomas Huth
2017-01-27 14:51 ` [Qemu-devel] " Thomas Huth
2017-01-27 16:40 ` [Qemu-trivial] " Alistair Francis
2017-01-27 16:40 ` Alistair Francis
2017-01-27 16:52 ` [Qemu-trivial] " Peter Maydell
2017-01-27 16:52 ` Peter Maydell
2017-01-27 17:18 ` Markus Armbruster [this message]
2017-01-27 17:18 ` Markus Armbruster
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=87wpdga0c6.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=alistair.francis@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=thuth@redhat.com \
/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.