Re: Redesign of QEMU startup & initial configuration

[Paolo Bonzini]

On 12/13/21 16:28, Markus Armbruster wrote:
> 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 :)

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.