From: "Eduardo Habkost" <ehabkost@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
peter.maydell@linaro.org, mst@redhat.com, somlo@cmu.edu,
qemu-devel@nongnu.org, rjones@redhat.com, pbonzini@redhat.com,
lersek@redhat.com
Subject: Re: [Qemu-devel] [PATCHv7 5/6] fw_cfg: move qdev_init_nofail() from fw_cfg_init1() to callers
Date: Fri, 7 Jul 2017 16:54:16 -0300 [thread overview]
Message-ID: <20170707195416.GK10776@localhost.localdomain> (raw)
In-Reply-To: <20170707193029.GB12152@localhost.localdomain>
On Fri, Jul 07, 2017 at 04:30:29PM -0300, Eduardo Habkost wrote:
> On Fri, Jul 07, 2017 at 08:18:20PM +0200, Igor Mammedov wrote:
> > On Fri, 7 Jul 2017 12:09:56 -0300
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > > On Fri, Jul 07, 2017 at 04:58:17PM +0200, Igor Mammedov wrote:
> > > > On Fri, 7 Jul 2017 10:13:00 -0300
> > > > "Eduardo Habkost" <ehabkost@redhat.com> wrote:
> > > [...]
> > > > > I don't disagree with adding the assert(), but it looks like
> > > > > making fw_cfg_find() return NULL if there are multiple devices
> > > > > can be useful for realize.
> > > > >
> > > > > In this case, it looks like Mark is relying on that in
> > > > > fw_cfg_common_realize(): if multiple devices are created,
> > > > > fw_cfg_find() will return NULL, and realize will fail. This
> > > > > sounds like a more graceful way to handle multiple-device
> > > > > creation than crashing on fw_cfg_find(). This is the solution
> > > > > used by find_vmgenid_dev()/vmgenid_realize(), BTW.
> > > >
> > > > I suspect that find_vmgenid_dev() works by luck as it could be
> > > > placed only as /machine/peripheral-anon/foo1 or /machine/peripheral/foo2
> > > > object_resolve_partial_path() : machine
> > > > object_resolve_partial_path() : peripheral-anon => foo1
> > > > object_resolve_partial_path() : peripheral => foo2
> > > > if (found /* foo2 */) {
> > > > if (obj /* foo1 */) {
> > > > return NULL;
> > >
> > > I don't think this is luck: object_resolve_partial_path() is
> > > explicitly documented to always return NULL if multiple matches
> > > are found, and I don't see any bug in its implementation that
> > > would break that functionality.
> >
> > Maybe I'm reading it wrong, but consider following:
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg460692.html
> >
> > it looks to me that using ambiguous argument is necessary for
> > duplicate detection to work correctly.
>
> Oh, good catch, I think I see the bug now. We need to write a
> test case and fix that.
I could reproduce it with the following test case.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
diff --git a/tests/check-qom-proplist.c b/tests/check-qom-proplist.c
index 8e432e9..c320cff 100644
--- a/tests/check-qom-proplist.c
+++ b/tests/check-qom-proplist.c
@@ -568,6 +568,29 @@ static void test_dummy_delchild(void)
object_unparent(OBJECT(dev));
}
+static void test_qom_partial_path(void)
+{
+ Object *root = object_get_objects_root();
+ Object *o = object_new(TYPE_DUMMY);
+ Object *o1_1 = object_new(TYPE_DUMMY);
+ Object *o1_2 = object_new(TYPE_DUMMY);
+ Object *o2 = object_new(TYPE_DUMMY);
+
+ object_property_add_child(root, "o", o, &error_abort);
+ object_property_add_child(o, "o1", o1_1, &error_abort);
+ object_property_add_child(o, "o2", o1_2, &error_abort);
+ object_property_add_child(root, "o2", o2, &error_abort);
+
+ g_assert(!object_resolve_path_type("", TYPE_DUMMY, NULL));
+ g_assert(!object_resolve_path("o2", NULL));
+ g_assert(object_resolve_path("o1", NULL) == o1_1);
+
+ object_unref(o);
+ object_unref(o2);
+ object_unref(o1_1);
+ object_unref(o1_2);
+}
+
int main(int argc, char **argv)
{
g_test_init(&argc, &argv, NULL);
@@ -585,6 +608,7 @@ int main(int argc, char **argv)
g_test_add_func("/qom/proplist/getenum", test_dummy_getenum);
g_test_add_func("/qom/proplist/iterator", test_dummy_iterator);
g_test_add_func("/qom/proplist/delchild", test_dummy_delchild);
+ g_test_add_func("/qom/path/resolve/partial", test_qom_partial_path);
return g_test_run();
}
--
Eduardo
next prev parent reply other threads:[~2017-07-07 19:54 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 14:07 [Qemu-devel] [PATCHv7 0/6] fw_cfg: qdev-related tidy-ups Mark Cave-Ayland
2017-06-29 14:07 ` [Qemu-devel] [PATCHv7 1/6] fw_cfg: don't map the fw_cfg IO ports in fw_cfg_io_realize() Mark Cave-Ayland
2017-06-29 14:07 ` [Qemu-devel] [PATCHv7 2/6] fw_cfg: move setting of FW_CFG_VERSION_DMA bit to fw_cfg_init1() Mark Cave-Ayland
2017-06-29 14:07 ` [Qemu-devel] [PATCHv7 3/6] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path Mark Cave-Ayland
2017-07-03 9:42 ` Igor Mammedov
2017-07-04 18:14 ` Mark Cave-Ayland
2017-06-29 14:07 ` [Qemu-devel] [PATCHv7 4/6] fw_cfg: add assert() to ensure the fw_cfg device has been added as a child property Mark Cave-Ayland
2017-06-29 14:07 ` [Qemu-devel] [PATCHv7 5/6] fw_cfg: move qdev_init_nofail() from fw_cfg_init1() to callers Mark Cave-Ayland
2017-07-03 9:39 ` Igor Mammedov
2017-07-04 18:08 ` Mark Cave-Ayland
2017-07-07 11:33 ` Igor Mammedov
2017-07-07 13:12 ` Mark Cave-Ayland
2017-07-07 13:26 ` Eduardo Habkost
2017-07-07 13:54 ` Mark Cave-Ayland
2017-07-07 14:48 ` Eduardo Habkost
2017-07-07 16:16 ` Mark Cave-Ayland
2017-07-07 14:44 ` Igor Mammedov
2017-07-07 14:50 ` Eduardo Habkost
2017-07-07 15:07 ` Eduardo Habkost
2017-07-07 16:20 ` Mark Cave-Ayland
2017-07-10 8:01 ` Igor Mammedov
2017-07-10 14:53 ` Eduardo Habkost
2017-07-10 15:23 ` Igor Mammedov
2017-07-10 17:38 ` Eduardo Habkost
2017-07-11 18:05 ` Mark Cave-Ayland
2017-07-10 7:49 ` Igor Mammedov
2017-07-10 14:51 ` Eduardo Habkost
2017-07-07 13:13 ` Eduardo Habkost
2017-07-07 14:58 ` Igor Mammedov
2017-07-07 15:09 ` Eduardo Habkost
2017-07-07 18:18 ` Igor Mammedov
2017-07-07 19:30 ` Eduardo Habkost
2017-07-07 19:54 ` Eduardo Habkost [this message]
2017-07-07 20:03 ` Laszlo Ersek
2017-07-07 16:13 ` Mark Cave-Ayland
2017-06-29 14:07 ` [Qemu-devel] [PATCHv7 6/6] fw_cfg: move QOM type defines and fw_cfg types into fw_cfg.h Mark Cave-Ayland
2017-06-29 15:32 ` [Qemu-devel] [PATCHv7 0/6] fw_cfg: qdev-related tidy-ups Gabriel L. Somlo
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=20170707195416.GK10776@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=lersek@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=somlo@cmu.edu \
/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.