Daniel P. Berrangé <berrange@redhat.com> writes:
On Wed, Nov 24, 2021 at 02:50:11PM +0100, Markus Armbruster wrote:
Damien Hedde <damien.hedde@greensocs.com> writes:
The biggest difference is the fw_cfg option I think: it is related
with the rom_set_order_override()/rom_reset_order_override() (line 17
and 25). There is also the usb devices parts in between. I lack the
knowledge about fw_cfg/usb to tell if it is important or not.
What I wanted to say is I don't know if the difference is
acceptable. If we want device_add to support all -device use cases, it
is not. In that case we need to stop either in the middle of this
function (line 15) or at the end (better with your sketch in mind).
Note that rom_set_order_override()/rom_reset_order_override() only
set/reset a switch variable that changes how fw_cfg files are
sorted. It could be integrated into device_add code (and removed from
the above function) without changing the behavior.
For me, the part that puts me off is interleaving CLI and QMP.
We process the CLI in an order few people understand, and only while
staring at the code. That's bad.
Injecting QMP at certain points in that sequence can only make it worse.
Yep, I share your unease here.. especially wrt this quoted text
from later:
> >> Users can do as much or as little with the CLI as they want. You'd
> >> probably want to set up a QMP monitor and no more.
I would say that is a case of overkill. It can only make our
lives harder as maintainers in the long term, if we have to
worry about such arbitrary mixing of QMP and CLI. This is
also why I'm pretty uneasy about the 'preconfig' stuff as
implemented today in general.
It is a half-way house that doesn't really give mgmt apps
what they want, which is a 100% QAPI-only config. If mgmt
apps start using preconfig, it won't make life any better
for them and will also lock QEMU maintainers into supporting
this half-way house.
Misunderstanding? The paragraph you quoted is about this design:
1. Start event loop
2. Feed it CLI left to right. Each option runs a handler just like each
QMP command does.
Options that read a configuration file inject the file into the feed.
Options that create a monitor create it suspended.
Options may advance the phase / run state, and they may require
certain phase(s).
3. When we're done with CLI, resume any monitors we created.
4. Monitors now feed commands to the event loop. Commands may advance
the phase / run state, and they may require certain phase(s).
Users can do as much or as little with the CLI as they want. You'd
probably want to set up a QMP monitor and no more.
device_add becomes possible at a certain state of the phase / run state
machine. It changes from cold to hot plug at a certain later state.
Certainly enables 100% QAPI-only config. It just doesn't *force* you to
100%. Feature.
We have a bit of a track record with QEMU of introducing
partial solutions and never quite finishing the job. There's
little strong incentive to ever finish it, if you can freely
mix both old and new style forever, and thus maintainers are
burdened forever with both.
IMHO, we should only try to support the non-mixed scenarios
- 100% of hardware configured via CLI args
- 100% of hardware configured via QAPI (whether live in
QMP, or fed in via a QAPI based JSON/YAML config file)
so that we only have two clear cases we need to worry about
dealing with.
Focus our efforts 100% of the 100% QAPI scenario and don't
divert energy into short term hybrid solutions.
The design above pretty much requires 100% QAPI.
It's based on the notion that there's no real difference between a CLI
option and a QMP command that doesn't return a value. So treat the CLI
more like a monitor.
For sanity's sake, make it not race with the other monitors by starting
them suspended.
This design is arguably *less* hybrid than one that treats a (severely
dumbed down) CLI unlike a monitor.