On 11/13/21 08:52, Markus Armbruster wrote:
I'm not asking what to do "if it hurts", or "if you want a cold-plugged
device". I'm asking whether there's a reason for ever wanting hot plug
instead of cold plug. Or in other words, what can hot plug possibly
gain us over cold plug?
As far as I know, the answer is "nothing but trouble".
Yes, I agree.
If that's true, then what we should tell users is to stick to -device
for initial configuration, and stay away from device_add.
Yes, which is one issue with stabilizing -preconfig. It's not clear
what exactly it is solving.
The boat for this has sailed. The only sane way to do this is a new binary.
"Ideally" still applies to any new binary.
Well, "ideally" any new binary would only have a few command line
options, and ordering would be mostly irrelevant. For example I'd
expect a QMP binary to only have a few options, mostly for
debugging/development (-L, -trace) and for process-wide settings (such
as -name).
This is where we disagree. For me, a new, alternative qemu-system-FOO binary
should be able to replace the warty one we have.
One important kind of user is management applications. Libvirt
developers tell us that they'd like to configure as much as possible via
QMP. Another kind of user dear to me is me^H^Hdevelopers. For ad hoc
testing, having to configure via QMP is a pain we'd rathe do without. I
don't want to remain stuck on the traditional binary, I want to do this
with the new one.
Why do you care? For another example, you can use "reboot" or
"systemctl isolate reboot.target" and they end up doing the same thing.
As long as qemu_init invokes qmp_machine_set, qmp_accel_set,
qmp_device_add, qmp_plugin_add, qmp_cont, etc. to do its job, the
difference between qemu-system-* and qemu-qmp-* is a couple thousands
lines of boring code that all but disappears once the VM is up and
running. IOW, with the right design (e.g. shortcut options for QOM
properties good; dozens of global variables bad), there's absolutely no
issue with some people using qemu-system-* and some using qemu-qmp-*.
Likewise, we'd fail QMP commands that are "out of phase".
@allow-preconfig is a crutch that only exists because we're afraid (with
reason) of hidden assumptions in QMP commands.
At this point, it's not even like that anymore (except for block devices
because my patches haven't been applied).
My point is that we still have quite a few commands without
'allow-preconfig' mostly because we are afraid of allowing them in
preconfig state, not because of true phase dependencies.
I think there's very few of them, if any (outside the block layer for
which patches exist), and those are due to distraction more than fear.
qapi/*.json has 216 commands, of which 26 carry 'allow-preconfig'.
Well,
https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg01597.html
alone would more than double that. :)
Places like machine.json, machine-target.json, migration.json,
replay.json have a lot of commands that are, obviously, almost entirely
not suitable for preconfig. I don't think there are many commands left,
I'd guess maybe 30 (meaning that ~60% are done).
Paolo
