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)
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
