Re: Redesign of QEMU startup & initial configuration

[Markus Armbruster]

Paolo Bonzini <pbonzini@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.