[PATCH] tools/libxl: add missing blank in message

Alan Robinson posted 1 patch 2 years, 9 months ago
Test gitlab-ci failed
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20210723102308.5332-1-Alan.Robinson@fujitsu.com
There is a newer version of this series
tools/libs/light/libxl_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[PATCH] tools/libxl: add missing blank in message
Posted by Alan Robinson 2 years, 9 months ago
From: Alan Robinson <alan.robinson@fujitsu.com>

Add trailing blank to first part of concatenated string giving
"an emulated" instead of "anemulated".

Signed-off-by: Alan Robinson <alan.robinson@fujitsu.com>
---
 tools/libs/light/libxl_dm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
index dbd3c7f278..755641604a 100644
--- a/tools/libs/light/libxl_dm.c
+++ b/tools/libs/light/libxl_dm.c
@@ -1893,7 +1893,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
                 if (format == NULL) {
                     LOGD(WARN, guest_domid,
                          "Unable to determine disk image format: %s\n"
-                         "Disk will be available via PV drivers but not as an"
+                         "Disk will be available via PV drivers but not as an "
                          "emulated disk.",
                          disks[i].vdev);
                     continue;
@@ -1905,7 +1905,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
 
                 if (!target_path) {
                     LOGD(WARN, guest_domid, "No way to get local access disk to image: %s\n"
-                         "Disk will be available via PV drivers but not as an"
+                         "Disk will be available via PV drivers but not as an "
                          "emulated disk.",
                          disks[i].vdev);
                     continue;
-- 
2.26.2


Re: [PATCH] tools/libxl: add missing blank in message
Posted by Juergen Gross 2 years, 9 months ago
On 23.07.21 12:23, Alan Robinson wrote:
> From: Alan Robinson <alan.robinson@fujitsu.com>
> 
> Add trailing blank to first part of concatenated string giving
> "an emulated" instead of "anemulated".
> 
> Signed-off-by: Alan Robinson <alan.robinson@fujitsu.com>
> ---
>   tools/libs/light/libxl_dm.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
> index dbd3c7f278..755641604a 100644
> --- a/tools/libs/light/libxl_dm.c
> +++ b/tools/libs/light/libxl_dm.c
> @@ -1893,7 +1893,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
>                   if (format == NULL) {
>                       LOGD(WARN, guest_domid,
>                            "Unable to determine disk image format: %s\n"
> -                         "Disk will be available via PV drivers but not as an"
> +                         "Disk will be available via PV drivers but not as an "
>                            "emulated disk.",

I'd rather have a longer line without splitting the message (splitting
after the '\n' is fine, of course). This will make it easier to find the
coding emitting the message when searching for the whole printed line.


Juergen
Re: [PATCH] tools/libxl: add missing blank in message
Posted by Ian Jackson 2 years, 9 months ago
Juergen Gross writes ("Re: [PATCH] tools/libxl: add missing blank in message"):
> On 23.07.21 12:23, Alan Robinson wrote:
> > From: Alan Robinson <alan.robinson@fujitsu.com>
> > 
> > Add trailing blank to first part of concatenated string giving
> > "an emulated" instead of "anemulated".

Alan, thanks:

Acked-by: Ian Jackson <iwj@xenproject.org>

and queued.

> > -                         "Disk will be available via PV drivers but not as an"
> > +                         "Disk will be available via PV drivers but not as an "
> >                            "emulated disk.",
> 
> I'd rather have a longer line without splitting the message (splitting
> after the '\n' is fine, of course). This will make it easier to find the
> coding emitting the message when searching for the whole printed line.

I would be fine with this, and I can see how it is an improvement.
However, Alan's patch is a step in the right direction so should go in
right away.

Ian.