From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9vxg-00083Z-9K for qemu-devel@nongnu.org; Sat, 01 Oct 2011 05:34:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9vxe-0006zf-Ku for qemu-devel@nongnu.org; Sat, 01 Oct 2011 05:34:24 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:56399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9vxe-0006zT-H5 for qemu-devel@nongnu.org; Sat, 01 Oct 2011 05:34:22 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p918DAab027710 for ; Sat, 1 Oct 2011 04:13:10 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p919YEM5458284 for ; Sat, 1 Oct 2011 05:34:18 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p919YDSi021299 for ; Sat, 1 Oct 2011 06:34:13 -0300 From: "Aneesh Kumar K.V" In-Reply-To: <87pqih2im0.fsf@skywalker.in.ibm.com> References: <20110929232824.7CBA73FC28@buildbot.b1-systems.de> <87pqih2im0.fsf@skywalker.in.ibm.com> Date: Sat, 01 Oct 2011 15:03:23 +0530 Message-ID: <87mxdl2h0c.fsf@skywalker.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] buildbot failure in qemu on default_x86_64_rhel5 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: gollub@b1-systems.de, lcapitulino@redhat.com, qemu-devel@nongnu.org, agraf@suse.de On Sat, 01 Oct 2011 14:28:47 +0530, "Aneesh Kumar K.V" wrote: > On Fri, 30 Sep 2011 09:26:53 +0100, Stefan Hajnoczi = wrote: > > On Fri, Sep 30, 2011 at 12:28 AM, wrote: > > > The Buildbot has detected a new failure on builder default_x86_64_rhe= l5 while building qemu. > > > Full details are available at: > > > =C2=A0http://buildbot.b1-systems.de/qemu/builders/default_x86_64_rhel= 5/builds/24 > >=20 > > Build error on RHEL 5 in virtio-9p-handle.c: > > /home/buildbot/slave-public/default_x86_64_rhel5/build/hw/9pfs/virtio-9= p-handle.c: > > In function 'handle_utimensat': > > /home/buildbot/slave-public/default_x86_64_rhel5/build/hw/9pfs/virtio-9= p-handle.c:377: > > warning: implicit declaration of function 'futimens' > > /home/buildbot/slave-public/default_x86_64_rhel5/build/hw/9pfs/virtio-9= p-handle.c:377: > > warning: nested extern declaration of 'futimens' > >=20 > > RHEL 5 only has glibc 2.5 but futimens(2) was introduced in glibc 2.6. >=20 > We can make handle only available to glibc 2.6 and above . Handle fs > drive will anyhow require a 2.6.39 kernel. Something like. >=20 I guess the below is better. I haven't built test the changes on rhel5 yet. >>From c8e781fc8077587d23fcf658c14b5992282563a8 Mon Sep 17 00:00:00 2001 From: Aneesh Kumar K.V Date: Sat, 1 Oct 2011 14:59:42 +0530 Subject: [PATCH] hw/9pfs: Fix build error on platform that don't support fu= timens Signed-off-by: Aneesh Kumar K.V --- hw/9pfs/virtio-9p-handle.c | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c index 860b0e3..9e9ceb3 100644 --- a/hw/9pfs/virtio-9p-handle.c +++ b/hw/9pfs/virtio-9p-handle.c @@ -386,12 +386,17 @@ static int handle_utimensat(FsContext *ctx, V9fsPath = *fs_path, int fd, ret; struct handle_data *data =3D (struct handle_data *)ctx->private; =20 +#ifdef CONFIG_UTIMENSAT fd =3D open_by_handle(data->mountfd, fs_path->data, O_NONBLOCK); if (fd < 0) { return fd; } ret =3D futimens(fd, buf); close(fd); +#else + ret =3D -1; + errno =3D ENOSYS; +#endif return ret; } =20 @@ -591,8 +596,16 @@ static int handle_init(FsContext *ctx) int ret, mnt_id; struct statfs stbuf; struct file_handle fh; - struct handle_data *data =3D g_malloc(sizeof(struct handle_data)); + struct handle_data *data; =20 +#ifndef CONFIG_UTIMENSAT + /* + * We support handle fs driver only if all related + * syscalls are provided by host. + */ + return -1; +#endif + data =3D g_malloc(sizeof(struct handle_data)); data->mountfd =3D open(ctx->fs_root, O_DIRECTORY); if (data->mountfd < 0) { ret =3D data->mountfd; --=20 1.7.4.1