From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScJ7Y-0001PZ-0A for qemu-devel@nongnu.org; Wed, 06 Jun 2012 12:30:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScJ6n-0002RS-Dd for qemu-devel@nongnu.org; Wed, 06 Jun 2012 12:30:07 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:38427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScJ6n-0002RB-3w for qemu-devel@nongnu.org; Wed, 06 Jun 2012 12:29:21 -0400 Message-ID: <4FCF855D.8050208@weilnetz.de> Date: Wed, 06 Jun 2012 18:29:17 +0200 From: Stefan Weil MIME-Version: 1.0 References: <20120224195143.GA16353@vostro.hallyn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [BUG QEMU 1.1] virtio-9p-handle does not compile List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Hallyn Cc: "aliguori@us.ibm.com" , Stefano Stabellini , "qemu-devel@nongnu.org" , aneesh.kumar@linux.vnet.ibm.com Am 06.06.2012 12:50, schrieb Stefano Stabellini: > Hi Anthony, > currently QEMU 1.1 doesn't compile virtfs correctly on Ubuntu: > > qemu/hw/9pfs/virtio-9p-handle.c: In function =E2=80=98handle_update_fil= e_cred=E2=80=99: > qemu/hw/9pfs/virtio-9p-handle.c:66:58: error: =E2=80=98AT_EMPTY_PATH=E2= =80=99 undeclared (first use in this function) > qemu/hw/9pfs/virtio-9p-handle.c:66:58: note: each undeclared identifier= is reported only once for each function it appears in > qemu/hw/9pfs/virtio-9p-handle.c: In function =E2=80=98handle_lstat=E2=80= =99: > qemu/hw/9pfs/virtio-9p-handle.c:87:34: error: =E2=80=98AT_EMPTY_PATH=E2= =80=99 undeclared (first use in this function) > qemu/hw/9pfs/virtio-9p-handle.c: In function =E2=80=98handle_symlink=E2= =80=99: > qemu/hw/9pfs/virtio-9p-handle.c:314:62: error: =E2=80=98AT_EMPTY_PATH=E2= =80=99 undeclared (first use in this function) > qemu/hw/9pfs/virtio-9p-handle.c: In function =E2=80=98handle_link=E2=80= =99: > qemu/hw/9pfs/virtio-9p-handle.c:337:45: error: =E2=80=98AT_EMPTY_PATH=E2= =80=99 undeclared (first use in this function) > qemu/hw/9pfs/virtio-9p-handle.c: In function =E2=80=98handle_chown=E2=80= =99: > qemu/hw/9pfs/virtio-9p-handle.c:373:58: error: =E2=80=98AT_EMPTY_PATH=E2= =80=99 undeclared (first use in this function) > > > a patch was sent on the 24th of Feb to fix the issue (also see below): > > http://marc.info/?l=3Dqemu-devel&m=3D133011313912147 > > Even though it is not particularly pretty, in the absence of better > alternatives it should probably be applied. > > Cheers, > > Stefano > > > > > > On Fri, 24 Feb 2012, Serge Hallyn wrote: >> If AT_EMPTY_PATH is not in one of the included files, go ahead and >> define it. qemu won't compile on ubuntu for me without this. >> >> (Note - alternatively we could #include to pick >> up the definitions there) >> >> Signed-off-by: Serge Hallyn >> --- >> hw/9pfs/virtio-9p-handle.c | 9 +++++++++ >> 1 files changed, 9 insertions(+), 0 deletions(-) >> >> diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c >> index f96d17a..e403a84 100644 >> --- a/hw/9pfs/virtio-9p-handle.c >> +++ b/hw/9pfs/virtio-9p-handle.c >> @@ -39,6 +39,15 @@ >> #ifndef BTRFS_SUPER_MAGIC >> #define BTRFS_SUPER_MAGIC 0x9123683E >> #endif >> +#ifndef AT_REMOVEDIR >> +#define AT_REMOVEDIR 0x200 >> +#endif >> +#ifndef AT_EMPTY_PATH >> +#define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */ >> +#endif >> +#ifndef O_PATH >> +#define O_PATH 010000000 >> +#endif >> >> struct handle_data { >> int mountfd; >> --=20 >> 1.7.9 The patch will fix the compiler error messages, but will the resulting code work? Maybe it has runtime dependencies (Linux kernel?) which should be checked at runtime. Would an enhanced test in configure be a better solution? It could disable VirtFS automatically if the definitions are missing. On Ubuntu Lenny, there is no definition for AT_EMPTY_PATH, not even in linux/fcntl.h. Regards, Stefan W.