From: Markus Armbruster <armbru@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: ThinerLogoer <logoerthiner1@163.com>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Daniel P.Berrangé" <berrange@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
"Jagannathan Raman" <jag.raman@oracle.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Ani Sinha" <anisinha@redhat.com>,
"Xiao Guangrong" <xiaoguangrong.eric@gmail.com>,
"Daniel Henrique Barboza" <danielhb413@gmail.com>,
"Greg Kurz" <groug@kaod.org>, "Eric Blake" <eblake@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>
Subject: Re: [PATCH v3 11/11] machine: Improve error message when using default RAM backend id
Date: Fri, 25 Aug 2023 11:56:24 +0200 [thread overview]
Message-ID: <87sf87momv.fsf@pond.sub.org> (raw)
In-Reply-To: <bd8f7f13-b982-6cf6-1ef7-16b4738b94ac@redhat.com> (David Hildenbrand's message of "Fri, 25 Aug 2023 11:13:02 +0200")
David Hildenbrand <david@redhat.com> writes:
> On 25.08.23 11:10, Markus Armbruster wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>
>>> On 25.08.23 08:57, ThinerLogoer wrote:
>>>> Hello,
>>>>
>>>> At 2023-08-23 23:34:11, "David Hildenbrand" <david@redhat.com> wrote:
>>>>> For migration purposes, users might want to reuse the default RAM
>>>>> backend id, but specify a different memory backend.
>>>>>
>>>>> For example, to reuse "pc.ram" on q35, one has to set
>>>>> -machine q35,memory-backend=pc.ram
>>>>> Only then, can a memory backend with the id "pc.ram" be created
>>>>> manually.
>>>>>
>>>>> Let's improve the error message.
>>>>>
>>>>> Unfortuantely, we cannot use error_append_hint(), because the caller
>>>>> passes &error_fatal.
>>>>>
>>>>> Suggested-by: ThinerLogoer <logoerthiner1@163.com>
>>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>>> ---
>>>>> hw/core/machine.c | 4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/hw/core/machine.c b/hw/core/machine.c
>>>>> index f0d35c6401..dbcd124d45 100644
>>>>> --- a/hw/core/machine.c
>>>>> +++ b/hw/core/machine.c
>>>>> @@ -1382,7 +1382,9 @@ void machine_run_board_init(MachineState *machine, const char *mem_path, Error *
>>>>> machine_class->default_ram_id)) {
>>>>> error_setg(errp, "object name '%s' is reserved for the default"
>>>>> " RAM backend, it can't be used for any other purposes."
>>>>> - " Change the object's 'id' to something else",
>>>>> + " Change the object's 'id' to something else or disable"
>>>>> + " automatic creation of the default RAM backend by setting"
>>>>> + " the 'memory-backend' machine property",
>>>>> machine_class->default_ram_id);
>>>>> return;
>>>>> }
>>>>
>>>> I'd suggest a more explicit version:
>>>>
>>>> " Change the object's 'id' to something else or disable"
>>>> " automatic creation of the default RAM backend by appending"
>>>> " 'memory-backend={machine_class->default_ram_id}' in '-machine' arguments",
>>>
>>>
>>> Thanks, I'll do:
>>>
>>> diff --git a/hw/core/machine.c b/hw/core/machine.c
>>> index f0d35c6401..cd0fd6cdd1 100644
>>> --- a/hw/core/machine.c
>>> +++ b/hw/core/machine.c
>>> @@ -1382,8 +1382,10 @@ void machine_run_board_init(MachineState *machine, const char *mem_path, Error *
>>> machine_class->default_ram_id)) {
>>> error_setg(errp, "object name '%s' is reserved for the default"
>>> " RAM backend, it can't be used for any other purposes."
>>> - " Change the object's 'id' to something else",
>>> - machine_class->default_ram_id);
>>> + " Change the object's 'id' to something else or disable"
>>> + " automatic creation of the default RAM backend by appending"
>>> + " 'memory-backend=%s' in '-machine' arguments",
>>> + machine_class->default_ram_id, machine_class->default_ram_id);
>>> return;
>>> }
>>> if (!create_default_memdev(current_machine, mem_path, errp)) {
>>
>
> Hi Markus,
>
>> error_setg()'s function comment specifies:
>> * The resulting message should be a single phrase, with no newline or
>> * trailing punctuation.
>> Please use error_append_hint(), like so
>
> Please see the patch description: "Unfortunately, we cannot use error_append_hint(), because the caller passes &error_fatal."
>
> How should I deal with that?
qapi/error.h tells you :)
* = Creating errors =
[...]
* Create an error and add additional explanation:
* error_setg(errp, "invalid quark");
* error_append_hint(errp, "Valid quarks are up, down, strange, "
* "charm, top, bottom.\n");
* This may require use of ERRP_GUARD(); more on that below.
[...]
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
* - It must not be dereferenced, because it may be null.
* - It should not be passed to error_prepend() or
* error_append_hint(), because that doesn't work with &error_fatal.
* ERRP_GUARD() lifts these restrictions.
*
* To use ERRP_GUARD(), add it right at the beginning of the function.
* @errp can then be used without worrying about the argument being
* NULL or &error_fatal.
*
* Using it when it's not needed is safe, but please avoid cluttering
* the source with useless code.
*
* = Converting to ERRP_GUARD() =
*
* To convert a function to use ERRP_GUARD():
*
* 0. If the Error ** parameter is not named @errp, rename it to
* @errp.
*
* 1. Add an ERRP_GUARD() invocation, by convention right at the
* beginning of the function. This makes @errp safe to use.
*
* 2. Replace &err by errp, and err by *errp. Delete local variable
* @err.
*
* 3. Delete error_propagate(errp, *errp), replace
* error_propagate_prepend(errp, *errp, ...) by error_prepend(errp, ...)
*
* 4. Ensure @errp is valid at return: when you destroy *errp, set
* *errp = NULL.
*
* Example:
*
* bool fn(..., Error **errp)
* {
* Error *err = NULL;
*
* foo(arg, &err);
* if (err) {
* handle the error...
* error_propagate(errp, err);
* return false;
* }
* ...
* }
*
* becomes
*
* bool fn(..., Error **errp)
* {
* ERRP_GUARD();
*
* foo(arg, errp);
* if (*errp) {
* handle the error...
* return false;
* }
* ...
* }
*
* For mass-conversion, use scripts/coccinelle/errp-guard.cocci.
Questions?
>> error_setg(errp, "object name '%s' is reserved for the default"
>> " RAM backend, it can't be used for any other purposes",
>> machine_class->default_ram_id);
>> error_append_hint(errp,
>> "Change the object's 'id' to something else or disable"
>> " automatic creation of the default RAM backend by appending"
>> " 'memory-backend=%s' in '-machine' arguments\n",
>> machine_class->default_ram_id);
>> Moreover:
>> * "object name" feels off, we're talking about IDs, aren't we?
>
> Yes, I think so.
>
>> * "appending X in Y" should be "appending X to Y". Consider "setting
>> 'memory-backend=%s' with -machine".
>>
>
> Can do, thanks.
next prev parent reply other threads:[~2023-08-25 9:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-23 15:34 [PATCH v3 00/11] memory-backend-file related improvements and VM templating support David Hildenbrand
2023-08-23 15:34 ` [PATCH v3 01/11] nvdimm: Reject writing label data to ROM instead of crashing QEMU David Hildenbrand
2023-08-23 15:34 ` [PATCH v3 02/11] softmmu/physmem: Distinguish between file access mode and mmap protection David Hildenbrand
2023-08-23 20:21 ` Peter Xu
2023-08-23 15:34 ` [PATCH v3 03/11] backends/hostmem-file: Add "rom" property to support VM templating with R/O files David Hildenbrand
2023-09-01 12:50 ` Markus Armbruster
2023-08-23 15:34 ` [PATCH v3 04/11] softmmu/physmem: Remap with proper protection in qemu_ram_remap() David Hildenbrand
2023-08-23 20:21 ` Peter Xu
2023-08-29 11:18 ` Philippe Mathieu-Daudé
2023-08-23 15:34 ` [PATCH v3 05/11] softmmu/physmem: Bail out early in ram_block_discard_range() with readonly files David Hildenbrand
2023-08-23 20:21 ` Peter Xu
2023-08-23 15:34 ` [PATCH v3 06/11] softmmu/physmem: Fail creation of new files in file_ram_open() with readonly=true David Hildenbrand
2023-08-23 20:22 ` Peter Xu
2023-08-23 15:34 ` [PATCH v3 07/11] softmmu/physmem: Never return directories from file_ram_open() David Hildenbrand
2023-08-23 20:22 ` Peter Xu
2023-08-23 15:34 ` [PATCH v3 08/11] docs: Don't mention "-mem-path" in multi-process.rst David Hildenbrand
2023-08-23 15:34 ` [PATCH v3 09/11] docs: Start documenting VM templating David Hildenbrand
2023-08-29 11:25 ` Philippe Mathieu-Daudé
2023-08-23 15:34 ` [PATCH v3 10/11] softmmu/physmem: Hint that "readonly=on, rom=off" exists when opening file R/W for private mapping fails David Hildenbrand
2023-08-23 15:34 ` [PATCH v3 11/11] machine: Improve error message when using default RAM backend id David Hildenbrand
2023-08-25 6:57 ` ThinerLogoer
2023-08-25 7:36 ` [PATCH " David Hildenbrand
2023-08-25 9:10 ` Markus Armbruster
2023-08-25 9:13 ` David Hildenbrand
2023-08-25 9:56 ` Markus Armbruster [this message]
2023-08-25 9:59 ` David Hildenbrand
2023-08-25 10:10 ` David Hildenbrand
2023-08-29 11:29 ` Philippe Mathieu-Daudé
2023-09-01 12:52 ` Markus Armbruster
2023-08-29 8:31 ` Mario Casquero
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=87sf87momv.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=anisinha@redhat.com \
--cc=berrange@redhat.com \
--cc=danielhb413@gmail.com \
--cc=david@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=elena.ufimtseva@oracle.com \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=jag.raman@oracle.com \
--cc=logoerthiner1@163.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=stefanha@redhat.com \
--cc=xiaoguangrong.eric@gmail.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.