All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Gavin Shan <gshan@redhat.com>
Cc: qemu-arm@nongnu.org,  qemu-devel@nongnu.org,
	 qemu-riscv@nongnu.org, peter.maydell@linaro.org,
	 imammedo@redhat.com,  b.galvani@gmail.com,
	strahinja.p.jankovic@gmail.com,  sundeep.lkml@gmail.com,
	kfting@nuvoton.com,  wuhaotsh@google.com,
	 nieklinnenbank@gmail.com, rad@semihalf.com,
	 quic_llindhol@quicinc.com, marcin.juszkiewicz@linaro.org,
	 eduardo@habkost.net, marcel.apfelbaum@gmail.com,
	 philmd@linaro.org,  wangyanan55@huawei.com,
	vijai@behindbytes.com,  palmer@dabbelt.com,
	 alistair.francis@wdc.com, bin.meng@windriver.com,
	 liwei1518@gmail.com,  dbarboza@ventanamicro.com,
	zhiwei_liu@linux.alibaba.com,  shan.gavin@gmail.com
Subject: Re: [PATCH v8 1/9] machine: Use error handling when CPU type is checked
Date: Wed, 29 Nov 2023 09:20:41 +0100	[thread overview]
Message-ID: <87bkbdnf6u.fsf@pond.sub.org> (raw)
In-Reply-To: <20231129042012.277831-2-gshan@redhat.com> (Gavin Shan's message of "Wed, 29 Nov 2023 14:20:04 +1000")

Gavin Shan <gshan@redhat.com> writes:

> QEMU will be terminated if the specified CPU type isn't supported
> in machine_run_board_init(). The list of supported CPU type names
> is tracked by mc->valid_cpu_types.

Suggest to drop the second sentence.

> The error handling can be used to propagate error messages, to be
> consistent how the errors are handled for other situations in the
> same function.
>
> No functional change intended.
>
> Suggested-by: Igor Mammedov <imammedo@redhat.com>
> Signed-off-by: Gavin Shan <gshan@redhat.com>
> ---
> v8: Drop @local_err and use @errp to be compatible with
>     ERRP_GUARD()                                          (Phil)
> ---
>  hw/core/machine.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 0c17398141..bde7f4af6d 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -1466,15 +1466,16 @@ void machine_run_board_init(MachineState *machine, const char *mem_path, Error *
>  
>          if (!machine_class->valid_cpu_types[i]) {
>              /* The user specified CPU is not valid */
> -            error_report("Invalid CPU type: %s", machine->cpu_type);
> -            error_printf("The valid types are: %s",
> -                         machine_class->valid_cpu_types[0]);
> +            error_setg(errp, "Invalid CPU type: %s", machine->cpu_type);
> +            error_append_hint(errp, "The valid types are: %s",
> +                              machine_class->valid_cpu_types[0]);
>              for (i = 1; machine_class->valid_cpu_types[i]; i++) {
> -                error_printf(", %s", machine_class->valid_cpu_types[i]);
> +                error_append_hint(errp, ", %s",
> +                                  machine_class->valid_cpu_types[i]);
>              }
> -            error_printf("\n");
>  
> -            exit(1);
> +            error_append_hint(&errp, "\n");
> +            return;
>          }
>      }

This cleans up an anti-pattern: use of error_report() within a function that
returns errors through an Error **errp parameter.

Cleanup, not bug fix, because the only caller passes &error_abort.

Suggest to start the commit message with a mention of the anti-pattern.
Here's how I'd write it:

    Functions that use an Error **errp parameter to return errors should
    not also report them to the user, because reporting is the caller's
    job.

    machine_run_board_init() violates this principle: it calls
    error_report(), error_printf(), and exit(1) when the machine doesn't
    support the requested CPU type.

    Clean this up by using error_setg() and error_append_hint() instead.
    No functional change, as the only caller passes &error_fatal.

Whether you use my suggestion or not:
Reviewed-by: Markus Armbruster <armbru@redhat.com>



  reply	other threads:[~2023-11-29  8:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29  4:20 [PATCH v8 0/9] Unified CPU type check Gavin Shan
2023-11-29  4:20 ` [PATCH v8 1/9] machine: Use error handling when CPU type is checked Gavin Shan
2023-11-29  8:20   ` Markus Armbruster [this message]
2023-12-01  3:33     ` Gavin Shan
2023-11-29  4:20 ` [PATCH v8 2/9] machine: Introduce helper is_cpu_type_supported() Gavin Shan
2023-12-01 10:53   ` Philippe Mathieu-Daudé
2023-12-03 23:13     ` Gavin Shan
2024-01-05 11:10       ` Philippe Mathieu-Daudé
2023-11-29  4:20 ` [PATCH v8 3/9] machine: Improve is_cpu_type_supported() Gavin Shan
2023-12-01 10:57   ` Philippe Mathieu-Daudé
2023-12-03 23:20     ` Gavin Shan
2023-12-03 23:30       ` Gavin Shan
2023-11-29  4:20 ` [PATCH v8 4/9] machine: Print CPU model name instead of CPU type Gavin Shan
2023-12-01 10:58   ` Philippe Mathieu-Daudé
2023-11-29  4:20 ` [PATCH v8 5/9] hw/arm/virt: Hide host CPU model for tcg Gavin Shan
2023-11-29  4:20 ` [PATCH v8 6/9] hw/arm/virt: Check CPU type in machine_run_board_init() Gavin Shan
2023-11-29  4:20 ` [PATCH v8 7/9] hw/arm/sbsa-ref: " Gavin Shan
2023-11-29  4:20 ` [PATCH v8 8/9] hw/arm: " Gavin Shan
2023-11-29  4:20 ` [PATCH v8 9/9] hw/riscv/shakti_c: " Gavin Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkbdnf6u.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=alistair.francis@wdc.com \
    --cc=b.galvani@gmail.com \
    --cc=bin.meng@windriver.com \
    --cc=dbarboza@ventanamicro.com \
    --cc=eduardo@habkost.net \
    --cc=gshan@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kfting@nuvoton.com \
    --cc=liwei1518@gmail.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=marcin.juszkiewicz@linaro.org \
    --cc=nieklinnenbank@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=quic_llindhol@quicinc.com \
    --cc=rad@semihalf.com \
    --cc=shan.gavin@gmail.com \
    --cc=strahinja.p.jankovic@gmail.com \
    --cc=sundeep.lkml@gmail.com \
    --cc=vijai@behindbytes.com \
    --cc=wangyanan55@huawei.com \
    --cc=wuhaotsh@google.com \
    --cc=zhiwei_liu@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.