From: Fiona Ebner <f.ebner@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 2/8] config to command: add one '-global' option for each flag
Date: Fri, 7 Mar 2025 11:14:42 +0100 [thread overview]
Message-ID: <ead3cd43-9042-4993-a1ce-68d201eff3f1@proxmox.com> (raw)
In-Reply-To: <590e5331-b0c6-4998-bafe-6efbdb8c64a6@proxmox.com>
Am 07.03.25 um 11:05 schrieb Dominik Csapak:
> On 3/7/25 11:00, Fiona Ebner wrote:
>> Am 07.03.25 um 10:54 schrieb Dominik Csapak:
>>> On 3/6/25 13:55, Fiona Ebner wrote:
>>>> Am 06.03.25 um 13:15 schrieb Dominik Csapak:
>>>>> On 3/6/25 13:13, Fiona Ebner wrote:
>>>>>> Am 06.03.25 um 11:44 schrieb Dominik Csapak:
>>>>>>> If we have multiple 'globalFlags', we have to encode each one
>>>>>>> separately
>>>>>>> on the commandline with '-global OPTION', since QEMU does not
>>>>>>> allow to
>>>>>>> have multiple options here.
>>>>>>>
>>>>>>> We currently only have one such flag that used the 'globalFlags'
>>>>>>> list,
>>>>>>> so it never popped up. (All other uses directly add an option to the
>>>>>>> commandline)
>>>>>>>
>>>>>>> Avoid future bugs by fixing it now.
>>>>>>>
>>>>>>
>>>>>> So there is no real point to collecting the flags in the first place?
>>>>>> I.e. we could also get rid of the variable and have the single
>>>>>> current
>>>>>> user of the variable add the flag directly on the commandline too. Or
>>>>>> otherwise, we could change the other users and collect all flags with
>>>>>> this variable. Pre-existing of course, but ideally, we could avoid
>>>>>> the
>>>>>> mishmash.
>>>>>>
>>>>>
>>>>> Sorry this could have been more clear here:
>>>>> I add to the flags in one of the following patches, so i sent this
>>>>> in preparation of that (could possibly be squashed)
>>>>
>>>> Yes, I understand that. I still think the status quo with mixing two
>>>> different approaches might not be best. It's not going to be a blocker
>>>> for the series, but I wanted to mention it, if you want to go for
>>>> avoiding it.
>>>>
>>>>> I did not want to touch the other places, since that in turn changes
>>>>> the order of the qemu commandline (which sometimes has unintended side
>>>>> effects, e.g. in combination with the 'args' parameter)
>>>>
>>>> Are you sure? Custom 'args' are always added last so that shouldn't
>>>> matter.
>>>>
>>>> The only thing that would change by removing the global flags variable
>>>> is having "-global kvm-pit.lost_tick_policy=discard" earlier in the
>>>> commandline. I think that should be fine. In particular QEMU's
>>>> qemu_init() function has a call to user_register_global_props() which
>>>> handles all global properties at the same time, so I think changing the
>>>> order should be fine in (almost?) all cases.
>>>
>>> I'll test that, but imho it would better to do the reverse here?
>>> So don't interject '-gloabl' parameters throughout config2command, but
>>> add them to the globalFlags and output them together at the end?
>>>
>>> we'd have to touch the same number of tests i think, but it seems less
>>> confusing to me (also in the resulting commandline we'd have all
>>> global options together then)
>>>
>>> Or is there a better argument for injecting the global parameters
>>> in the middle?
>>
>> It avoids the need for the variable to collect and passing it around and
>> to remember adding future ones to that variable too.
>>
>> It doesn't make a difference from QEMUs perspective, but would slightly
>> improve readability for humans looking at the commandline.
>>
>> Note that I already suggested collecting all in the variable as an
>> approach above. I just want to avoid the mishmash.
>
> OK, which approach would you prefer? (I don't have a strong feeling in
> either direction
> and doing the cleanup now seems to not be a lot of work)
>
I don't have a strong opinion either, but slightly prefer the
no-variable/collect approach. Just because cfg2cmd is already quite
bloated. We can always switch to collecting again, if we continue adding
global flags and think it's worth for readability on the cmdline.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-03-07 10:15 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 10:44 [pve-devel] [PATCH qemu-server 0/8] disable S3/S4 power states by default Dominik Csapak
2025-03-06 10:44 ` [pve-devel] [RFC PATCH qemu-server 1/8] tests: cfg2cmd: pin QEMU version Dominik Csapak
2025-03-06 12:00 ` Fiona Ebner
2025-03-06 12:07 ` Dominik Csapak
2025-03-06 12:43 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 2/8] config to command: add one '-global' option for each flag Dominik Csapak
2025-03-06 12:13 ` Fiona Ebner
2025-03-06 12:15 ` Dominik Csapak
2025-03-06 12:55 ` Fiona Ebner
2025-03-07 9:54 ` Dominik Csapak
2025-03-07 10:00 ` Fiona Ebner
2025-03-07 10:05 ` Dominik Csapak
2025-03-07 10:14 ` Fiona Ebner [this message]
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 3/8] meta info: also add current pve-machine version Dominik Csapak
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 4/8] machine: correctly select pve machine version for non pinned windows guests Dominik Csapak
2025-03-06 13:10 ` Fiona Ebner
2025-03-06 13:36 ` Dominik Csapak
2025-03-06 14:10 ` Fiona Ebner
2025-03-06 14:14 ` Fiona Ebner
2025-03-06 14:15 ` Dominik Csapak
2025-03-06 14:20 ` Fiona Ebner
2025-03-07 9:55 ` Dominik Csapak
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 5/8] machine: incorporate pve machine version when pinning " Dominik Csapak
2025-03-06 14:32 ` Fiona Ebner
2025-03-07 9:58 ` Dominik Csapak
2025-03-07 10:06 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 6/8] machine: add S3/S4 power state properties Dominik Csapak
2025-03-06 14:52 ` Fiona Ebner
2025-03-07 10:02 ` Dominik Csapak
2025-03-07 10:10 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 7/8] machine: bump pve machine version and reverse the s3/s4 defaults Dominik Csapak
2025-03-06 15:04 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 8/8] tests: cfg2cmd: add test for windows machine pinning from meta info Dominik Csapak
2025-03-06 15:10 ` Fiona Ebner
2025-03-07 14:46 ` [pve-devel] [PATCH qemu-server 0/8] disable S3/S4 power states by default Dominik Csapak
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=ead3cd43-9042-4993-a1ce-68d201eff3f1@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal