From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, pkrempa@redhat.com,
qemu-block@nongnu.org, mst@redhat.com, mreitz@redhat.com,
pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 5/6] vl: Create block backends before setting machine properties
Date: Tue, 5 Mar 2019 12:34:36 +0100 [thread overview]
Message-ID: <f1cff39e-9612-397a-d408-f0ef8610f699@redhat.com> (raw)
In-Reply-To: <8736o1vc5g.fsf@dusky.pond.sub.org>
On 3/5/19 11:38 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
>> On 2/25/19 7:37 PM, Markus Armbruster wrote:
>>> qemu-system-FOO's main() acts on command line arguments in its own
>>> idiosyncratic order. There's not much method to its madness.
>>> Whenever we find a case where one kind of command line argument needs
>>> to refer to something created for another kind later, we rejigger the
>>> order.
>>>
>>> Block devices get created long after machine properties get processed.
>>> Therefore, block device machine properties can be created, but not
>>> set. No such properties exist. But the next commit will create some.
>>> Time to rejigger again: create block devices earlier.
>>>
>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>>> ---
>>> vl.c | 66 ++++++++++++++++++++++++++++++------------------------------
>>> 1 file changed, 33 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/vl.c b/vl.c
>>> index 6ce3d2d448..5cb0810ffa 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -4232,6 +4232,39 @@ int main(int argc, char **argv, char **envp)
>>> exit(0);
>>> }
>>>
>>
>> Can we extract this from the main, maybe as "parse_blockdev()"? This
>> will ease further :)
>
> I can try and see whether I like it.
>
>>> + /* If the currently selected machine wishes to override the units-per-bus
>>> + * property of its default HBA interface type, do so now. */
>>> + if (machine_class->units_per_default_bus) {
>>> + override_max_devs(machine_class->block_default_type,
>>> + machine_class->units_per_default_bus);
>>> + }
>>> +
>>> + /* open the virtual block devices */
>>> + while (!QSIMPLEQ_EMPTY(&bdo_queue)) {
>>> + BlockdevOptions_queue *bdo = QSIMPLEQ_FIRST(&bdo_queue);
>>> +
>>> + QSIMPLEQ_REMOVE_HEAD(&bdo_queue, entry);
>>> + loc_push_restore(&bdo->loc);
>>> + qmp_blockdev_add(bdo->bdo, &error_fatal);
>>> + loc_pop(&bdo->loc);
>>> + qapi_free_BlockdevOptions(bdo->bdo);
>>> + g_free(bdo);
>>> + }
>>> + if (snapshot || replay_mode != REPLAY_MODE_NONE) {
>>> + qemu_opts_foreach(qemu_find_opts("drive"), drive_enable_snapshot,
>>> + NULL, NULL);
>>> + }
>>> + if (qemu_opts_foreach(qemu_find_opts("drive"), drive_init_func,
>>> + &machine_class->block_default_type, &error_fatal)) {
>>> + /* We printed help */
>>> + exit(0);
>>> + }
>>> +
>>> + default_drive(default_cdrom, snapshot, machine_class->block_default_type, 2,
>>> + CDROM_OPTS);
>>> + default_drive(default_floppy, snapshot, IF_FLOPPY, 0, FD_OPTS);
>>> + default_drive(default_sdcard, snapshot, IF_SD, 0, SD_OPTS);
>>> +
>>
>> Can you add a comment here such:
>>
>> /*
>> * Arguments setting properties on devices has to be processed before
>> * the following qemu_opt_foreach(...machine_set_property...) call.
>> */
>
> Hmm, is this accurate? The issue this patch addresses is
>
> "arguments creating block backends have to be processed before
> machine_set_property()",
>
> which is an instance of
>
> "arguments creating backends ...",
>
> which is an instance of
>
> "arguments creating stuff machine property values can reference ..."
>
> The patch only addresses the instance "block backends". I have no
> appetite for attacking more general problems right now.
>
> See also
>
> Subject: Re: [Qemu-devel] [PATCH RFC 0/3] qdev: order devices by priority before creating them
> Date: Wed, 11 May 2016 09:51:39 +0200
> Message-ID: <87y47hhw1g.fsf@dusky.pond.sub.org>
> https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg01589.html
>
> Subject: Re: [Qemu-devel] [PATCH] vl: Delay initialization of memory backends
> Date: Fri, 02 Sep 2016 08:13:17 +0200
> Message-ID: <87poomg77m.fsf@dusky.pond.sub.org>
> https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg00163.html
>
> That said, I'm fine with adding a comment explaining the more general
> mess. Can you give me some hints on what future readers will find
> useful?
This can be as simple as:
/*
* Arguments creating block backends have to be processed before
* machine_set_property().
*/
parse_blockdev(...);
So if I have to hack around in the future I'd look at the commit
introducing this comment:
Block devices get created long after machine properties get processed.
Therefore, block device machine properties can be created, but not
set. No such properties exist. But the next commit will create some.
So I won't rejig this at his previous place :)
>
>>> machine_opts = qemu_get_machine_opts();
>>> qemu_opt_foreach(machine_opts, machine_set_property, current_machine,
>>> &error_fatal);
>>> @@ -4355,39 +4388,6 @@ int main(int argc, char **argv, char **envp)
>>> ram_mig_init();
>>> dirty_bitmap_mig_init();
>>>
>>> - /* If the currently selected machine wishes to override the units-per-bus
>>> - * property of its default HBA interface type, do so now. */
>>> - if (machine_class->units_per_default_bus) {
>>> - override_max_devs(machine_class->block_default_type,
>>> - machine_class->units_per_default_bus);
>>> - }
>>> -
>>> - /* open the virtual block devices */
>>> - while (!QSIMPLEQ_EMPTY(&bdo_queue)) {
>>> - BlockdevOptions_queue *bdo = QSIMPLEQ_FIRST(&bdo_queue);
>>> -
>>> - QSIMPLEQ_REMOVE_HEAD(&bdo_queue, entry);
>>> - loc_push_restore(&bdo->loc);
>>> - qmp_blockdev_add(bdo->bdo, &error_fatal);
>>> - loc_pop(&bdo->loc);
>>> - qapi_free_BlockdevOptions(bdo->bdo);
>>> - g_free(bdo);
>>> - }
>>> - if (snapshot || replay_mode != REPLAY_MODE_NONE) {
>>> - qemu_opts_foreach(qemu_find_opts("drive"), drive_enable_snapshot,
>>> - NULL, NULL);
>>> - }
>>> - if (qemu_opts_foreach(qemu_find_opts("drive"), drive_init_func,
>>> - &machine_class->block_default_type, &error_fatal)) {
>>> - /* We printed help */
>>> - exit(0);
>>> - }
>>> -
>>> - default_drive(default_cdrom, snapshot, machine_class->block_default_type, 2,
>>> - CDROM_OPTS);
>>> - default_drive(default_floppy, snapshot, IF_FLOPPY, 0, FD_OPTS);
>>> - default_drive(default_sdcard, snapshot, IF_SD, 0, SD_OPTS);
>>> -
>>> qemu_opts_foreach(qemu_find_opts("mon"),
>>> mon_init_func, NULL, &error_fatal);
>>>
>>
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>
> Thanks!
>
next prev parent reply other threads:[~2019-03-05 11:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 18:37 [Qemu-devel] [RFC PATCH 0/6] pc: Support firmware configuration with -blockdev Markus Armbruster
2019-02-25 18:37 ` [Qemu-devel] [RFC PATCH 1/6] qdev: Fix latent bug with compat_props and onboard devices Markus Armbruster
2019-02-26 12:28 ` Marc-André Lureau
2019-02-25 18:37 ` [Qemu-devel] [RFC PATCH 2/6] qom: Move compat_props machinery from qdev to QOM Markus Armbruster
2019-02-26 12:44 ` Marc-André Lureau
2019-03-04 15:57 ` Philippe Mathieu-Daudé
2019-03-05 6:52 ` Markus Armbruster
2019-02-25 18:37 ` [Qemu-devel] [RFC PATCH 3/6] vl: Fix latent bug with -global and onboard devices Markus Armbruster
2019-02-26 12:45 ` Marc-André Lureau
2019-02-25 18:37 ` [Qemu-devel] [RFC PATCH 4/6] sysbus: Fix latent bug with " Markus Armbruster
2019-02-26 12:48 ` Marc-André Lureau
2019-03-04 16:03 ` Philippe Mathieu-Daudé
2019-03-04 18:45 ` Thomas Huth
2019-03-05 6:54 ` Markus Armbruster
2019-03-05 7:17 ` Thomas Huth
2019-02-25 18:37 ` [Qemu-devel] [RFC PATCH 5/6] vl: Create block backends before setting machine properties Markus Armbruster
2019-03-04 16:14 ` Philippe Mathieu-Daudé
2019-03-05 10:38 ` Markus Armbruster
2019-03-05 11:34 ` Philippe Mathieu-Daudé [this message]
2019-03-05 14:07 ` Markus Armbruster
2019-02-25 18:37 ` [Qemu-devel] [RFC PATCH 6/6] pc: Support firmware configuration with -blockdev Markus Armbruster
2019-02-26 9:43 ` Laszlo Ersek
2019-02-26 12:35 ` Markus Armbruster
2019-02-26 16:21 ` Laszlo Ersek
2019-03-04 17:50 ` Markus Armbruster
2019-03-05 17:08 ` Laszlo Ersek
2019-03-06 6:12 ` Markus Armbruster
2019-03-04 19:14 ` Philippe Mathieu-Daudé
2019-03-04 19:52 ` Philippe Mathieu-Daudé
2019-03-05 11:31 ` 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=f1cff39e-9612-397a-d408-f0ef8610f699@redhat.com \
--to=philmd@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=lersek@redhat.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-block@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 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).