Re: Redesign of QEMU startup & initial configuration

[Paolo Bonzini <pbonzini@redhat.com>]

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.
> 
>