* [PATCH] hw/core/qdev: Increase qdev_realize() kindness
@ 2020-06-20 15:38 Philippe Mathieu-Daudé
2020-07-04 16:47 ` Philippe Mathieu-Daudé
2020-07-05 5:46 ` Paolo Bonzini
0 siblings, 2 replies; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-20 15:38 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster
Cc: Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Philippe Mathieu-Daudé
Since commit 510ef98dca5, qdev_realize() aborts if bus-less
device is realized on a bus. Be kind with the developer by
displaying a hint about what is wrong.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
hw/core/qdev.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 2131c7f951..dd3c90d37a 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -392,8 +392,11 @@ bool qdev_realize(DeviceState *dev, BusState *bus, Error **errp)
if (bus) {
qdev_set_parent_bus(dev, bus);
- } else {
- assert(!DEVICE_GET_CLASS(dev)->bus_type);
+ } else if (DEVICE_GET_CLASS(dev)->bus_type) {
+ error_report("%s: Unexpected bus '%s' for device '%s'",
+ __func__, DEVICE_GET_CLASS(dev)->bus_type,
+ object_get_typename(OBJECT(dev)));
+ abort();
}
object_property_set_bool(OBJECT(dev), true, "realized", &err);
--
2.21.3
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] hw/core/qdev: Increase qdev_realize() kindness
2020-06-20 15:38 [PATCH] hw/core/qdev: Increase qdev_realize() kindness Philippe Mathieu-Daudé
@ 2020-07-04 16:47 ` Philippe Mathieu-Daudé
2020-07-05 5:46 ` Paolo Bonzini
1 sibling, 0 replies; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-07-04 16:47 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster
Cc: QEMU Trivial, Paolo Bonzini, Daniel P. Berrangé,
Eduardo Habkost
ping?
On 6/20/20 5:38 PM, Philippe Mathieu-Daudé wrote:
> Since commit 510ef98dca5, qdev_realize() aborts if bus-less
> device is realized on a bus. Be kind with the developer by
> displaying a hint about what is wrong.
>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/core/qdev.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index 2131c7f951..dd3c90d37a 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -392,8 +392,11 @@ bool qdev_realize(DeviceState *dev, BusState *bus, Error **errp)
>
> if (bus) {
> qdev_set_parent_bus(dev, bus);
> - } else {
> - assert(!DEVICE_GET_CLASS(dev)->bus_type);
> + } else if (DEVICE_GET_CLASS(dev)->bus_type) {
> + error_report("%s: Unexpected bus '%s' for device '%s'",
> + __func__, DEVICE_GET_CLASS(dev)->bus_type,
> + object_get_typename(OBJECT(dev)));
> + abort();
> }
>
> object_property_set_bool(OBJECT(dev), true, "realized", &err);
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] hw/core/qdev: Increase qdev_realize() kindness
2020-06-20 15:38 [PATCH] hw/core/qdev: Increase qdev_realize() kindness Philippe Mathieu-Daudé
2020-07-04 16:47 ` Philippe Mathieu-Daudé
@ 2020-07-05 5:46 ` Paolo Bonzini
2020-07-05 10:05 ` Philippe Mathieu-Daudé
1 sibling, 1 reply; 7+ messages in thread
From: Paolo Bonzini @ 2020-07-05 5:46 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, qemu-devel, Markus Armbruster
Cc: Daniel P. Berrangé, Eduardo Habkost
On 20/06/20 17:38, Philippe Mathieu-Daudé wrote:
> - } else {
> - assert(!DEVICE_GET_CLASS(dev)->bus_type);
> + } else if (DEVICE_GET_CLASS(dev)->bus_type) {
> + error_report("%s: Unexpected bus '%s' for device '%s'",
> + __func__, DEVICE_GET_CLASS(dev)->bus_type,
> + object_get_typename(OBJECT(dev)));
> + abort();
> }
>
Since there is an errp, should we use it and be even kinder?
Paolo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] hw/core/qdev: Increase qdev_realize() kindness
2020-07-05 5:46 ` Paolo Bonzini
@ 2020-07-05 10:05 ` Philippe Mathieu-Daudé
2020-07-05 11:14 ` Paolo Bonzini
0 siblings, 1 reply; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-07-05 10:05 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel, Markus Armbruster
Cc: Daniel P. Berrangé, Eduardo Habkost
On 7/5/20 7:46 AM, Paolo Bonzini wrote:
> On 20/06/20 17:38, Philippe Mathieu-Daudé wrote:
>> - } else {
>> - assert(!DEVICE_GET_CLASS(dev)->bus_type);
>> + } else if (DEVICE_GET_CLASS(dev)->bus_type) {
>> + error_report("%s: Unexpected bus '%s' for device '%s'",
>> + __func__, DEVICE_GET_CLASS(dev)->bus_type,
>> + object_get_typename(OBJECT(dev)));
>> + abort();
>> }
>>
>
> Since there is an errp, should we use it and be even kinder?
This is a programming error, not an user triggerable condition,
so I'm not sure. IOW this must not happen, but if it does, then
the error message helps the developer to notice the problem without
having to use gdb.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] hw/core/qdev: Increase qdev_realize() kindness
2020-07-05 10:05 ` Philippe Mathieu-Daudé
@ 2020-07-05 11:14 ` Paolo Bonzini
2020-07-05 11:59 ` Philippe Mathieu-Daudé
2020-07-06 6:48 ` Markus Armbruster
0 siblings, 2 replies; 7+ messages in thread
From: Paolo Bonzini @ 2020-07-05 11:14 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Daniel P. Berrangé, qemu-devel, Eduardo Habkost,
Markus Armbruster
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]
Are we sure that qdev_realize is never called with user-provided input? If
it's a programming error, the call chain will end up passing &error_abort
anyway, won't it?
Paolo
Il dom 5 lug 2020, 12:05 Philippe Mathieu-Daudé <f4bug@amsat.org> ha
scritto:
> On 7/5/20 7:46 AM, Paolo Bonzini wrote:
> > On 20/06/20 17:38, Philippe Mathieu-Daudé wrote:
> >> - } else {
> >> - assert(!DEVICE_GET_CLASS(dev)->bus_type);
> >> + } else if (DEVICE_GET_CLASS(dev)->bus_type) {
> >> + error_report("%s: Unexpected bus '%s' for device '%s'",
> >> + __func__, DEVICE_GET_CLASS(dev)->bus_type,
> >> + object_get_typename(OBJECT(dev)));
> >> + abort();
> >> }
> >>
> >
> > Since there is an errp, should we use it and be even kinder?
>
> This is a programming error, not an user triggerable condition,
> so I'm not sure. IOW this must not happen, but if it does, then
> the error message helps the developer to notice the problem without
> having to use gdb.
>
>
[-- Attachment #2: Type: text/html, Size: 1541 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] hw/core/qdev: Increase qdev_realize() kindness
2020-07-05 11:14 ` Paolo Bonzini
@ 2020-07-05 11:59 ` Philippe Mathieu-Daudé
2020-07-06 6:48 ` Markus Armbruster
1 sibling, 0 replies; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-07-05 11:59 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Markus Armbruster, Daniel P. Berrangé, qemu-devel,
Eduardo Habkost
On 7/5/20 1:14 PM, Paolo Bonzini wrote:
> Are we sure that qdev_realize is never called with user-provided input?
I am not sure, but ...
> If it's a programming error, the call chain will end up passing
> &error_abort anyway, won't it?
... this is a good point :)
>
> Paolo
>
> Il dom 5 lug 2020, 12:05 Philippe Mathieu-Daudé <f4bug@amsat.org
> <mailto:f4bug@amsat.org>> ha scritto:
>
> On 7/5/20 7:46 AM, Paolo Bonzini wrote:
> > On 20/06/20 17:38, Philippe Mathieu-Daudé wrote:
> >> - } else {
> >> - assert(!DEVICE_GET_CLASS(dev)->bus_type);
> >> + } else if (DEVICE_GET_CLASS(dev)->bus_type) {
> >> + error_report("%s: Unexpected bus '%s' for device '%s'",
> >> + __func__, DEVICE_GET_CLASS(dev)->bus_type,
> >> + object_get_typename(OBJECT(dev)));
> >> + abort();
> >> }
> >>
> >
> > Since there is an errp, should we use it and be even kinder?
>
> This is a programming error, not an user triggerable condition,
> so I'm not sure. IOW this must not happen, but if it does, then
> the error message helps the developer to notice the problem without
> having to use gdb.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] hw/core/qdev: Increase qdev_realize() kindness
2020-07-05 11:14 ` Paolo Bonzini
2020-07-05 11:59 ` Philippe Mathieu-Daudé
@ 2020-07-06 6:48 ` Markus Armbruster
1 sibling, 0 replies; 7+ messages in thread
From: Markus Armbruster @ 2020-07-06 6:48 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Markus Armbruster, Daniel P. Berrangé,
Philippe Mathieu-Daudé, Eduardo Habkost, qemu-devel
Paolo Bonzini <pbonzini@redhat.com> writes:
> Are we sure that qdev_realize is never called with user-provided input? If
The only way to call qdev_realize() with a user-provided bus is -device
/ device_add via qdev_device_add(). qdev_device_add() carefully checks
the user-provided bus before passing it to qdev_realize().
> it's a programming error, the call chain will end up passing &error_abort
> anyway, won't it?
Correct.
>
> Paolo
>
> Il dom 5 lug 2020, 12:05 Philippe Mathieu-Daudé <f4bug@amsat.org> ha
> scritto:
>
>> On 7/5/20 7:46 AM, Paolo Bonzini wrote:
>> > On 20/06/20 17:38, Philippe Mathieu-Daudé wrote:
>> >> - } else {
>> >> - assert(!DEVICE_GET_CLASS(dev)->bus_type);
>> >> + } else if (DEVICE_GET_CLASS(dev)->bus_type) {
>> >> + error_report("%s: Unexpected bus '%s' for device '%s'",
>> >> + __func__, DEVICE_GET_CLASS(dev)->bus_type,
>> >> + object_get_typename(OBJECT(dev)));
>> >> + abort();
>> >> }
>> >>
>> >
>> > Since there is an errp, should we use it and be even kinder?
>>
>> This is a programming error, not an user triggerable condition,
>> so I'm not sure. IOW this must not happen, but if it does, then
>> the error message helps the developer to notice the problem without
>> having to use gdb.
I don't bother with reporting impossible errors nicely. Statement, not
objection.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-07-06 6:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-06-20 15:38 [PATCH] hw/core/qdev: Increase qdev_realize() kindness Philippe Mathieu-Daudé
2020-07-04 16:47 ` Philippe Mathieu-Daudé
2020-07-05 5:46 ` Paolo Bonzini
2020-07-05 10:05 ` Philippe Mathieu-Daudé
2020-07-05 11:14 ` Paolo Bonzini
2020-07-05 11:59 ` Philippe Mathieu-Daudé
2020-07-06 6:48 ` Markus Armbruster
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).