On 12/13/21 16:28, Markus Armbruster wrote:
Paolo Bonzini <pbonz...@redhat.com> writes:
On 12/10/21 14:54, Markus Armbruster wrote:
I want an open path to a single binary. Taking years to get there is
fine.
The single binary is a distraction in my opinion. Imagine
instead of vl.c you have this in your second binary:
[...]
static void open_socket_and_monitor(void)
{
int nfds = check_socket_activation();
Chardev *chardev;
if (nfds > 1) {
error_report("QEMU only supports listening on one socket");
exit(1);
}
if (!nfds) {
ChardevBackend backend = {
.type = CHARDEV_BACKEND_KIND_STDIO,
.u.stdio.data = &(ChardevStdio) {
.has_signal = true,
.signal = false
}
};
chardev = qemu_chardev_new("#qmp0", TYPE_CHARDEV_STDIO, &backend, NULL,
&error_fatal);
} else {
ChardevBackend backend = {
.type = CHARDEV_BACKEND_KIND_SOCKET,
.u.socket.data = &(ChardevSocket) {
.addr = &(SocketAddressLegacy) {
.type = SOCKET_ADDRESS_LEGACY_KIND_FD,
.u.fd.data = &(String){
.str = (char *) stringify(FIRST_SOCKET_ACTIVATION_FD)
}
}
}
};
chardev = qemu_chardev_new("#qmp0", TYPE_CHARDEV_SOCKET, &backend, NULL,
&error_fatal);
}
monitor_init_qmp(chardev, true, &error_fatal);
}
void qemu_init(int argc, char **argv, char **envp)
{
error_init(argv[0]);
qemu_init_exec_dir(argv[0]);
qemu_init_subsystems();
/* Missing: parse -name, -sandbox, -trace, -L */
loc_set_none();
rcu_disable_atfork();
qemu_init_main_loop(&error_fatal);
cpu_timers_init();
open_socket_and_monitor();
init_displaystate();
os_setup_signal_handling();
}
This is the ultimate QEMU startup code. If we can get this code to
actually build a machine, you've reached the point where you don't care
about what is in the command line parser; and consequently you don't care
if there is one binary or two.
Define "you". Also explain why it should include me, because I think it
doesn't :)
Impersonal you. :)
By when can we have this second binary in master? Opinion, please, not
promise.
Define "have":
- a binary that builds
- a binary that builds a bootable guest
- a binary that builds any guest that the current well-maintained
targets can build, using a given (but roughly full-featured) subset of
options
Estimates for the first are easy (it's in my tree), estimates for the
second depends on somebody helping (upstreaming -M smp took months
between me being busy, reviewers being busy, and releases freezing
development), estimates for the third are hard.
Would you object to me expanding the CLI here to the point where I think
we can deprecate the old binary?
If yes, why?
Yes, for two reasons.
First, because there will be usually differences between the command
lines as mentioned elsewhere in the thread. qemu-system-* is a good
name, but one that is already taken by 15 years of docs using the
existing command line.
Second, because a command line is really hard to get right as complexity
increases. QMP is the way to go to get as clean as possible a
configuration mechanism. There *will* be a second set of warts layered
on top of the above code, and I don't want that.
Paolo
If no, the file names climain.c and qmpmain.c you mentioned upthread
won't last. Recommend to pick better names.
