From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hidetoshi Seto Subject: Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1 Date: Fri, 05 Nov 2010 15:32:08 +0900 Message-ID: <4CD3A4E8.9020504@jp.fujitsu.com> References: <4CB56715.7080605@jp.fujitsu.com> <4CB64FF6.5080906@jp.fujitsu.com> <20101104170303.GE15211@sequoia.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Blue Swirl , "Hao, Xudong" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Avi Kivity To: Chris Wright Return-path: Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]:44976 "EHLO fgwmail7.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750728Ab0KEGcl (ORCPT ); Fri, 5 Nov 2010 02:32:41 -0400 Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id oA56Wcwc016147 for (envelope-from seto.hidetoshi@jp.fujitsu.com); Fri, 5 Nov 2010 15:32:39 +0900 Received: from smail (m5 [127.0.0.1]) by outgoing.m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 9999645DE51 for ; Fri, 5 Nov 2010 15:32:38 +0900 (JST) Received: from s5.gw.fujitsu.co.jp (s5.gw.fujitsu.co.jp [10.0.50.95]) by m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 6D71345DE52 for ; Fri, 5 Nov 2010 15:32:38 +0900 (JST) Received: from s5.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id 506821DB805A for ; Fri, 5 Nov 2010 15:32:38 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.249.87.105]) by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id C8A541DB803C for ; Fri, 5 Nov 2010 15:32:34 +0900 (JST) In-Reply-To: <20101104170303.GE15211@sequoia.sous-sol.org> Sender: kvm-owner@vger.kernel.org List-ID: (2010/11/05 2:03), Chris Wright wrote: > * Hidetoshi Seto (seto.hidetoshi@jp.fujitsu.com) wrote: >> (2010/10/14 4:11), Blue Swirl wrote: >>> On Wed, Oct 13, 2010 at 8:00 AM, Hidetoshi Seto >>> wrote: >>>> (Add CC to kvm@vger) >>>> >>>> (2010/10/12 10:52), Hao, Xudong wrote: >>>>> Hi, >>>>> Currently qemu-kvm build fail on RHEL5 with gcc 4.1.2, build can pass on Fedora11 with gcc 4.4.1, can anybody look on RHEL5 system? >>>>> >>>>> Gcc: 4.1.2 >>>>> system: RHEL5.1 >>>>> qemu-kvm: 85566812a4f8cae721fea0224e05a7e75c08c5dd >>>>> >>>>> ... >>>>> LINK qemu-img >>>>> LINK qemu-io >>>>> CC libhw64/virtio-9p-local.o >>>>> cc1: warnings being treated as errors >>>>> /home/source/qemu-kvm/hw/virtio-9p-local.c: In function 'local_utimensat': >>>>> /home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat' >>>>> /home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat' >>>>> make[1]: *** [virtio-9p-local.o] Error 1 >>>>> make: *** [subdir-libhw64] Error 2 >>>>> >>>>> >>>>> Best Regards, >>>>> Xudong Hao >>>> >>>> It seems that this issue is caused by the old glibc. >>>> Though I don't know well about virtio-9p and suppose there >>>> should be better fix, I confirmed that following change >>>> removed the warnings. >>> >>> But then the system call will be made blindly without checking if the >>> kernel supports utimensat(). At the minimum, there should be a sane >>> response to ENOSYS error. >> >> Yes. But I'm not sure how this virtio-9p should behave if there is >> no utimensat. I think it will be better to fix this warning first >> to allow fellows using RHEL5 to restart contribute on qemu-kvm, >> and change this issue to virtio-9p specific problem to allow >> specialists of virtio-9p to have discussion for fix without >> bothering other developers. > > One way to workaround this is to simply not install libattr-devel > (effecitvely disabling virtio-9p). > > But I agree with Blue Swirl, need a better fallback plan. A qemu local > implementation of something like qemu_utimensat() that simply uses > glibc/kernel interface when available and falls back to using utimes() > makes sense to me. Then the worst case is loss of resolution from ns to > us. According to the commit 74bc02b2d2272dc88fb98d43e631eb154717f517, the title "Do not reset atime" can tell us that the original motivation to use utimensat() is not for the resolution. Anyway, I agree to have something like qemu_utimensat(). I made a patch for the first step, and will post it next to this reply. Thanks, H.Seto