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 :)
By when can we have this second binary in master? Opinion, please, not
promise.
Would you object to me expanding the CLI here to the point where I think
we can deprecate the old binary?
If yes, why?
If no, the file names climain.c and qmpmain.c you mentioned upthread
won't last. Recommend to pick better names.
