WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] libxl build errors in xen-unstable

To: Olaf Hering <olaf@xxxxxxxxx>
Subject: Re: [Xen-devel] libxl build errors in xen-unstable
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Tue, 31 May 2011 09:45:43 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 31 May 2011 06:39:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110530163326.GA24266@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <20110530163326.GA24266@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2011-05-30 at 17:33 +0100, Olaf Hering wrote:
> There are new build errors in xen-unstable since revision 23368.
> Wether the _libxl_paths.h.tmp/_libxl_paths.h errros/warnings are new, no
> idea.
[...]
> cmp: _libxl_paths.h.tmp: No such file or directory
> sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" _libxl_paths.h.tmp 
> >_libxl_paths.h.2.tmp
> if ! cmp _libxl_paths.h.2.tmp _libxl_paths.h; then mv -f _libxl_paths.h.2.tmp 
> _libxl_paths.h; fi
> Parsing libxl.idl
> cmp: _libxl_paths.h: No such file or directory

Presumably this also yields the correct return code to cause the mv to
happen, so you do end up with a _libxl_paths.h with stuff in it?

[...]
> libxl_exec.c:48: error: ignoring return value of 'atoi', declared with 
> attribute warn_unused_result
[...]
> libxl_exec.c:224: error: ignoring return value of 'write', declared with 
> attribute warn_unused_result
[...]
> libxl_device.c:488: error: ignoring return value of 'read', declared with 
> attribute warn_unused_result

Has someone got a bit carried away with the warn_unused_result attribute
in your distro/gcc/libc/etc? Applying that sort of attribute system wide
to such widespread functions seems like... trouble...

That said the atoi one is definitely a thinko on my part. (patch below)

The read/write ones are opposite ends of the notification pipe used when
the device model fails to start (to give the parent an fd to select on
so it can fail more quickly on qemu error).

I'm not sure there is much in the way of error handling which can or
should be done here, the parent will eventually timeout, much like if
the qemu process starts but fails initialise properly (i.e. hangs
instead of crashing).

I suppose we could check for EINTR and the like on the write side (being
careful not to get into a pointless loop) but on the read side we really
don't care about the result of the read, the wake up from select is the
important thing.

Ian.

8<--------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@xxxxxxxxxx>
# Date 1306830860 -3600
# Node ID acef384cf9ebbebde29b57a2fcbf2aef0b915497
# Parent  2e197702a9ab6d7fceeb27589d8ef88dd2c9741a
libxl: remove stray "atoi" in debug code.

I switched from atoi to strtol but failed to actually remove it...

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

diff -r 2e197702a9ab -r acef384cf9eb tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c  Tue May 31 09:33:27 2011 +0100
+++ b/tools/libxl/libxl_exec.c  Tue May 31 09:34:20 2011 +0100
@@ -47,7 +47,7 @@ static void check_open_fds(const char *w
     env_debug = getenv("_LIBXL_DEBUG_EXEC_FDS");
     if (!env_debug) return;
 
-    debug = strtol(env_debug, (char **) NULL, 10);atoi(env_debug);
+    debug = strtol(env_debug, (char **) NULL, 10);
     if (debug <= 0) return;
 
     for (i = 4; i < 256; i++) {



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel