qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] qemu-kvm build issue on RHEL5.1
@ 2010-10-12  1:52 Hao, Xudong
  2010-10-13  8:00 ` Hidetoshi Seto
  0 siblings, 1 reply; 17+ messages in thread
From: Hao, Xudong @ 2010-10-12  1:52 UTC (permalink / raw)
  To: qemu-devel@nongnu.org; +Cc: Avi Kivity

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1
  2010-10-12  1:52 [Qemu-devel] qemu-kvm build issue on RHEL5.1 Hao, Xudong
@ 2010-10-13  8:00 ` Hidetoshi Seto
  2010-10-13  8:13   ` Hao, Xudong
  2010-10-13 19:11   ` Blue Swirl
  0 siblings, 2 replies; 17+ messages in thread
From: Hidetoshi Seto @ 2010-10-13  8:00 UTC (permalink / raw)
  To: Hao, Xudong; +Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Avi Kivity

(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.

Thanks,
H.Seto

=====

[PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT

This removes following warnings on RHEL5, which has utimensat syscall
but has old glibc that doesn't have support for it:

hw/virtio-9p-local.c: In function 'local_utimensat':
hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat'
hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat'

and

hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this function)
hw/virtio-9p.c:1410: error: (Each undeclared identifier is reported only once
hw/virtio-9p.c:1410: error: for each function it appears in.)
hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this function)
hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this function)

Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
---
 hw/virtio-9p-local.c |    8 ++++++++
 hw/virtio-9p.c       |    9 +++++++++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 57f9243..e075c27 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -18,6 +18,9 @@
 #include <sys/socket.h>
 #include <sys/un.h>
 #include <attr/xattr.h>
+#ifndef CONFIG_UTIMENSAT
+#include <syscall.h>
+#endif
 
 static const char *rpath(FsContext *ctx, const char *path)
 {
@@ -476,7 +479,12 @@ static int local_chown(FsContext *fs_ctx, const char *path, FsCred *credp)
 static int local_utimensat(FsContext *s, const char *path,
 		       const struct timespec *buf)
 {
+#ifndef CONFIG_UTIMENSAT
+    return syscall(SYS_utimensat, AT_FDCWD, rpath(s, path), buf,
+                   AT_SYMLINK_NOFOLLOW);
+#else
     return utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
+#endif
 }
 
 static int local_remove(FsContext *ctx, const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 32fa3bc..efe5c51 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1393,6 +1393,15 @@ out:
     qemu_free(vs);
 }
 
+#ifndef CONFIG_UTIMENSAT
+#ifndef UTIME_NOW
+# define UTIME_NOW	((1l << 30) - 1l)
+#endif
+#ifndef UTIME_OMIT
+# define UTIME_OMIT	((1l << 30) - 2l)
+#endif
+#endif
+
 static void v9fs_setattr_post_chmod(V9fsState *s, V9fsSetattrState *vs, int err)
 {
     if (err == -1) {
-- 
1.7.3.1

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* RE: [Qemu-devel] qemu-kvm build issue on RHEL5.1
  2010-10-13  8:00 ` Hidetoshi Seto
@ 2010-10-13  8:13   ` Hao, Xudong
  2010-10-13 19:11   ` Blue Swirl
  1 sibling, 0 replies; 17+ messages in thread
From: Hao, Xudong @ 2010-10-13  8:13 UTC (permalink / raw)
  To: Hidetoshi Seto; +Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Avi Kivity

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.
> 
> Thanks,
> H.Seto
> 
> =====
> 
> [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT
> 
> This removes following warnings on RHEL5, which has utimensat syscall
> but has old glibc that doesn't have support for it:
> 
> hw/virtio-9p-local.c: In function 'local_utimensat':
> hw/virtio-9p-local.c:479: warning: implicit declaration of function
> 'utimensat' hw/virtio-9p-local.c:479: warning: nested extern
> declaration of 'utimensat' 
> 
> and
> 
> hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
> hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this
> function) hw/virtio-9p.c:1410: error: (Each undeclared identifier is
> reported only once hw/virtio-9p.c:1410: error: for each function it
> appears in.) 
> hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in
> this function) hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
> hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in
> this function) 
> 
> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
> ---
>  hw/virtio-9p-local.c |    8 ++++++++
>  hw/virtio-9p.c       |    9 +++++++++
>  2 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
> index 57f9243..e075c27 100644
> --- a/hw/virtio-9p-local.c
> +++ b/hw/virtio-9p-local.c
> @@ -18,6 +18,9 @@
>  #include <sys/socket.h>
>  #include <sys/un.h>
>  #include <attr/xattr.h>
> +#ifndef CONFIG_UTIMENSAT
> +#include <syscall.h>
> +#endif
> 
>  static const char *rpath(FsContext *ctx, const char *path)
>  {
> @@ -476,7 +479,12 @@ static int local_chown(FsContext *fs_ctx, const
>  char *path, FsCred *credp) static int local_utimensat(FsContext *s,
>  		       const char *path, const struct timespec *buf)
>  {
> +#ifndef CONFIG_UTIMENSAT
> +    return syscall(SYS_utimensat, AT_FDCWD, rpath(s, path), buf,
> +                   AT_SYMLINK_NOFOLLOW);
> +#else
>      return utimensat(AT_FDCWD, rpath(s, path), buf,
> AT_SYMLINK_NOFOLLOW); +#endif
>  }
> 
>  static int local_remove(FsContext *ctx, const char *path)
> diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
> index 32fa3bc..efe5c51 100644
> --- a/hw/virtio-9p.c
> +++ b/hw/virtio-9p.c
> @@ -1393,6 +1393,15 @@ out:
>      qemu_free(vs);
>  }
> 
> +#ifndef CONFIG_UTIMENSAT
> +#ifndef UTIME_NOW
> +# define UTIME_NOW	((1l << 30) - 1l)
> +#endif
> +#ifndef UTIME_OMIT
> +# define UTIME_OMIT	((1l << 30) - 2l)
> +#endif
> +#endif
> +
>  static void v9fs_setattr_post_chmod(V9fsState *s, V9fsSetattrState
>  *vs, int err) {
>      if (err == -1) {

Seto, your patch works fine for me, verified on my RHEL5 system.

Thanks,
Xudong

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1
  2010-10-13  8:00 ` Hidetoshi Seto
  2010-10-13  8:13   ` Hao, Xudong
@ 2010-10-13 19:11   ` Blue Swirl
  2010-10-14  0:33     ` Hidetoshi Seto
  1 sibling, 1 reply; 17+ messages in thread
From: Blue Swirl @ 2010-10-13 19:11 UTC (permalink / raw)
  To: Hidetoshi Seto
  Cc: Hao, Xudong, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Avi Kivity

On Wed, Oct 13, 2010 at 8:00 AM, Hidetoshi Seto
<seto.hidetoshi@jp.fujitsu.com> 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.

What happens if the system headers do not define SYS_utimensat?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1
  2010-10-13 19:11   ` Blue Swirl
@ 2010-10-14  0:33     ` Hidetoshi Seto
  2010-11-04 17:03       ` Chris Wright
  0 siblings, 1 reply; 17+ messages in thread
From: Hidetoshi Seto @ 2010-10-14  0:33 UTC (permalink / raw)
  To: Blue Swirl
  Cc: Hao, Xudong, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Avi Kivity

(2010/10/14 4:11), Blue Swirl wrote:
> On Wed, Oct 13, 2010 at 8:00 AM, Hidetoshi Seto
> <seto.hidetoshi@jp.fujitsu.com> 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. 

... Or is it better to put abort() here instead of syscall?

> 
> What happens if the system headers do not define SYS_utimensat?

I suppose build will fail, say, we might need incremental patch
named "fix build on RHEL4" or so.
But I have no idea, whether there could be a workaround if there
is no utimensat, whether we could provide something like wrapper
named compat_utimensat or qemu_utimensat, and/or whether it makes
sense if virtio-9p have dependency with presence of utimensat.


Thanks,
H.Seto

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1
  2010-10-14  0:33     ` Hidetoshi Seto
@ 2010-11-04 17:03       ` Chris Wright
  2010-11-05  6:32         ` Hidetoshi Seto
  2010-11-05  6:32         ` [Qemu-devel] [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2 Hidetoshi Seto
  0 siblings, 2 replies; 17+ messages in thread
From: Chris Wright @ 2010-11-04 17:03 UTC (permalink / raw)
  To: Hidetoshi Seto
  Cc: Blue Swirl, Hao, Xudong, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, Avi Kivity

* 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
> > <seto.hidetoshi@jp.fujitsu.com> 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.

thanks,
-chris

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1
  2010-11-04 17:03       ` Chris Wright
@ 2010-11-05  6:32         ` Hidetoshi Seto
  2010-11-05  6:32         ` [Qemu-devel] [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2 Hidetoshi Seto
  1 sibling, 0 replies; 17+ messages in thread
From: Hidetoshi Seto @ 2010-11-05  6:32 UTC (permalink / raw)
  To: Chris Wright
  Cc: Blue Swirl, Hao, Xudong, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, Avi Kivity

(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
>>> <seto.hidetoshi@jp.fujitsu.com> 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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Qemu-devel] [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2
  2010-11-04 17:03       ` Chris Wright
  2010-11-05  6:32         ` Hidetoshi Seto
@ 2010-11-05  6:32         ` Hidetoshi Seto
  2010-11-08  6:44           ` M. Mohan Kumar
  2010-11-14  5:58           ` [Qemu-devel] " Chris Wright
  1 sibling, 2 replies; 17+ messages in thread
From: Hidetoshi Seto @ 2010-11-05  6:32 UTC (permalink / raw)
  To: Chris Wright
  Cc: Blue Swirl, Hao, Xudong, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, Avi Kivity

This patch introduce a fallback mechanism for old systems that do not
support utimensat.  This will fix build failure with following warnings:

hw/virtio-9p-local.c: In function 'local_utimensat':
hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat'
hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat'

and

hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this function)
hw/virtio-9p.c:1410: error: (Each undeclared identifier is reported only once
hw/virtio-9p.c:1410: error: for each function it appears in.)
hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this function)
hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this function)

Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
---
 hw/virtio-9p-local.c |   32 ++++++++++++++++++++++++++++++--
 hw/virtio-9p.h       |   10 ++++++++++
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 0d52020..7811d2c 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -479,10 +479,38 @@ static int local_chown(FsContext *fs_ctx, const char *path, FsCred *credp)
     return -1;
 }
 
+/* TODO: relocate this to proper file, and make it more generic */
+static int qemu_utimensat(int dirfd, const char *path,
+                          const struct timespec *times, int flags)
+{
+#ifdef CONFIG_UTIMENSAT
+    return utimensat(dirfd, path, times, flags);
+#else
+    /*
+     * Fallback: use utimes() instead of utimensat().
+     * See commit 74bc02b2d2272dc88fb98d43e631eb154717f517 for known problem.
+     */
+    struct timeval tv[2];
+    int i;
+
+    for (i = 0; i < 2; i++) {
+        if (times[i].tv_nsec == UTIME_OMIT || times[i].tv_nsec == UTIME_NOW) {
+            tv[i].tv_sec = 0;
+            tv[i].tv_usec = 0;
+        } else {
+            tv[i].tv_sec = times[i].tv_sec;
+            tv[i].tv_usec = times[i].tv_nsec / 1000;
+        }
+    }
+
+    return utimes(path, &tv[0]);
+#endif
+}
+
 static int local_utimensat(FsContext *s, const char *path,
-		       const struct timespec *buf)
+                           const struct timespec *buf)
 {
-    return utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
+    return qemu_utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
 }
 
 static int local_remove(FsContext *ctx, const char *path)
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index 6c23319..d448d8a 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -8,6 +8,16 @@
 
 #include "file-op-9p.h"
 
+/* TODO: relocate this to proper file */
+#ifndef CONFIG_UTIMENSAT
+#ifndef UTIME_NOW
+# define UTIME_NOW     ((1l << 30) - 1l)
+#endif
+#ifndef UTIME_OMIT
+# define UTIME_OMIT    ((1l << 30) - 2l)
+#endif
+#endif
+
 /* The feature bitmap for virtio 9P */
 /* The mount point is specified in a config variable */
 #define VIRTIO_9P_MOUNT_TAG 0
-- 
1.7.3.1

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2
  2010-11-05  6:32         ` [Qemu-devel] [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2 Hidetoshi Seto
@ 2010-11-08  6:44           ` M. Mohan Kumar
  2010-11-12 12:33             ` Jes Sorensen
  2010-11-14  5:58           ` [Qemu-devel] " Chris Wright
  1 sibling, 1 reply; 17+ messages in thread
From: M. Mohan Kumar @ 2010-11-08  6:44 UTC (permalink / raw)
  To: qemu-devel
  Cc: Blue Swirl, Hidetoshi Seto, kvm@vger.kernel.org, Hao, Xudong,
	Chris Wright, Avi Kivity

> This patch introduce a fallback mechanism for old systems that do not
> support utimensat.  This will fix build failure with following warnings:
> 
> hw/virtio-9p-local.c: In function 'local_utimensat':
> hw/virtio-9p-local.c:479: warning: implicit declaration of function
> 'utimensat' hw/virtio-9p-local.c:479: warning: nested extern declaration
> of 'utimensat'
> 
> and
> 
> hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
> hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this
> function) hw/virtio-9p.c:1410: error: (Each undeclared identifier is
> reported only once hw/virtio-9p.c:1410: error: for each function it
> appears in.)
> hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this
> function) hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
> hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this
> function)
> 
> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
> ---
>  hw/virtio-9p-local.c |   32 ++++++++++++++++++++++++++++++--
>  hw/virtio-9p.h       |   10 ++++++++++
>  2 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
> index 0d52020..7811d2c 100644
> --- a/hw/virtio-9p-local.c
> +++ b/hw/virtio-9p-local.c
> @@ -479,10 +479,38 @@ static int local_chown(FsContext *fs_ctx, const char
> *path, FsCred *credp) return -1;
>  }
> 
> +/* TODO: relocate this to proper file, and make it more generic */
> +static int qemu_utimensat(int dirfd, const char *path,
> +                          const struct timespec *times, int flags)
> +{

IMHO, this code can be moved to cutils.c

> +#ifdef CONFIG_UTIMENSAT
> +    return utimensat(dirfd, path, times, flags);
> +#else
> +    /*
> +     * Fallback: use utimes() instead of utimensat().
> +     * See commit 74bc02b2d2272dc88fb98d43e631eb154717f517 for known
> problem. +     */
> +    struct timeval tv[2];
> +    int i;
> +
> +    for (i = 0; i < 2; i++) {
> +        if (times[i].tv_nsec == UTIME_OMIT || times[i].tv_nsec ==
> UTIME_NOW) { +            tv[i].tv_sec = 0;
> +            tv[i].tv_usec = 0;
> +        } else {
> +            tv[i].tv_sec = times[i].tv_sec;
> +            tv[i].tv_usec = times[i].tv_nsec / 1000;
> +        }
> +    }
> +
> +    return utimes(path, &tv[0]);
> +#endif

The idea of introducing utimensat was to avoid resetting atime to 1970-01-01 
05:30:00 (utime does not give option to not change atime). But as per utimes 
man page, if any of the time field is 0, it would be set to current time. As 
per stat man page, truncate will not update atime, only mtime will be updated.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2
  2010-11-08  6:44           ` M. Mohan Kumar
@ 2010-11-12 12:33             ` Jes Sorensen
  0 siblings, 0 replies; 17+ messages in thread
From: Jes Sorensen @ 2010-11-12 12:33 UTC (permalink / raw)
  To: M. Mohan Kumar
  Cc: Chris Wright, Hidetoshi Seto, kvm@vger.kernel.org, Hao, Xudong,
	qemu-devel, Blue Swirl, Avi Kivity

On 11/08/10 07:44, M. Mohan Kumar wrote:
>> This patch introduce a fallback mechanism for old systems that do not
>> support utimensat.  This will fix build failure with following warnings:
>>
>> hw/virtio-9p-local.c: In function 'local_utimensat':
>> hw/virtio-9p-local.c:479: warning: implicit declaration of function
>> 'utimensat' hw/virtio-9p-local.c:479: warning: nested extern declaration
>> of 'utimensat'
>>
>> and
>>
>> hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
>> hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this
>> function) hw/virtio-9p.c:1410: error: (Each undeclared identifier is
>> reported only once hw/virtio-9p.c:1410: error: for each function it
>> appears in.)
>> hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this
>> function) hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
>> hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this
>> function)
>>
>> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
>> ---
>>  hw/virtio-9p-local.c |   32 ++++++++++++++++++++++++++++++--
>>  hw/virtio-9p.h       |   10 ++++++++++
>>  2 files changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
>> index 0d52020..7811d2c 100644
>> --- a/hw/virtio-9p-local.c
>> +++ b/hw/virtio-9p-local.c
>> @@ -479,10 +479,38 @@ static int local_chown(FsContext *fs_ctx, const char
>> *path, FsCred *credp) return -1;
>>  }
>>
>> +/* TODO: relocate this to proper file, and make it more generic */
>> +static int qemu_utimensat(int dirfd, const char *path,
>> +                          const struct timespec *times, int flags)
>> +{
> 
> IMHO, this code can be moved to cutils.c

It's not a C utility function, so it really belongs in oslib-posix.c,
but otherwise I agree. This is emulation of a C library function, it
shouldn't be in the 9p code.

Cheers,
Jes

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Qemu-devel] Re: [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2
  2010-11-05  6:32         ` [Qemu-devel] [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2 Hidetoshi Seto
  2010-11-08  6:44           ` M. Mohan Kumar
@ 2010-11-14  5:58           ` Chris Wright
  2010-11-15  2:10             ` Hidetoshi Seto
  1 sibling, 1 reply; 17+ messages in thread
From: Chris Wright @ 2010-11-14  5:58 UTC (permalink / raw)
  To: Hidetoshi Seto
  Cc: Blue Swirl, kvm@vger.kernel.org, Hao, Xudong,
	qemu-devel@nongnu.org, Chris Wright, Avi Kivity

* Hidetoshi Seto (seto.hidetoshi@jp.fujitsu.com) wrote:
> +    /*
> +     * Fallback: use utimes() instead of utimensat().
> +     * See commit 74bc02b2d2272dc88fb98d43e631eb154717f517 for known problem.
> +     */
> +    struct timeval tv[2];
> +    int i;
> +
> +    for (i = 0; i < 2; i++) {
> +        if (times[i].tv_nsec == UTIME_OMIT || times[i].tv_nsec == UTIME_NOW) {
> +            tv[i].tv_sec = 0;
> +            tv[i].tv_usec = 0;

I don't think this is accurate in either case.  It will set the
atime, mtime, or both to 0.

For UTIME_NOW (in both) we'd simply pass NULL to utimes(2).  For
UTIME_OMIT (in both) we'd simply skip the call to utimes(2) altogether.

The harder part is a mixed mode (i.e. the truncate fix mentioned in the
above commit).  I think the only way to handle UTIME_NOW in one is to
call gettimeofday (or clock_gettime for better resolution) to find out
what current time is.  And for UTIME_OMIT call stat to find out what the
current setting is and reset to that value.  Both of those cases can
possibly zero out the extra precision (providing only seconds
resolution).

thanks,
-chris

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2
  2010-11-14  5:58           ` [Qemu-devel] " Chris Wright
@ 2010-11-15  2:10             ` Hidetoshi Seto
  2010-11-15  2:15               ` [Qemu-devel] [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT Hidetoshi Seto
  0 siblings, 1 reply; 17+ messages in thread
From: Hidetoshi Seto @ 2010-11-15  2:10 UTC (permalink / raw)
  To: Chris Wright
  Cc: kvm@vger.kernel.org, Jes.Sorensen, Hao, Xudong,
	qemu-devel@nongnu.org, Blue Swirl, mohan, Avi Kivity

(2010/11/14 14:58), Chris Wright wrote:
> * Hidetoshi Seto (seto.hidetoshi@jp.fujitsu.com) wrote:
>> +    /*
>> +     * Fallback: use utimes() instead of utimensat().
>> +     * See commit 74bc02b2d2272dc88fb98d43e631eb154717f517 for known problem.
>> +     */
>> +    struct timeval tv[2];
>> +    int i;
>> +
>> +    for (i = 0; i < 2; i++) {
>> +        if (times[i].tv_nsec == UTIME_OMIT || times[i].tv_nsec == UTIME_NOW) {
>> +            tv[i].tv_sec = 0;
>> +            tv[i].tv_usec = 0;
> 
> I don't think this is accurate in either case.  It will set the
> atime, mtime, or both to 0.
> 
> For UTIME_NOW (in both) we'd simply pass NULL to utimes(2).  For
> UTIME_OMIT (in both) we'd simply skip the call to utimes(2) altogether.
> 
> The harder part is a mixed mode (i.e. the truncate fix mentioned in the
> above commit).  I think the only way to handle UTIME_NOW in one is to
> call gettimeofday (or clock_gettime for better resolution) to find out
> what current time is.  And for UTIME_OMIT call stat to find out what the
> current setting is and reset to that value.  Both of those cases can
> possibly zero out the extra precision (providing only seconds
> resolution).

Thank you for comments!
I'll post an updated one soon.

Thanks,
H.Seto

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Qemu-devel] [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT
  2010-11-15  2:10             ` Hidetoshi Seto
@ 2010-11-15  2:15               ` Hidetoshi Seto
  2010-11-15  3:36                 ` [Qemu-devel] " Chris Wright
                                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Hidetoshi Seto @ 2010-11-15  2:15 UTC (permalink / raw)
  To: kvm@vger.kernel.org, qemu-devel@nongnu.org
  Cc: Blue Swirl, Jes.Sorensen, Hao, Xudong, Chris Wright, mohan,
	Avi Kivity

This patch introduce a fallback mechanism for old systems that do not
support utimensat().  This fix build failure with following warnings:

hw/virtio-9p-local.c: In function 'local_utimensat':
hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat'
hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat'

and:

hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this function)
hw/virtio-9p.c:1410: error: (Each undeclared identifier is reported only once
hw/virtio-9p.c:1410: error: for each function it appears in.)
hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this function)
hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this function)

v3:
  - Use better alternative handling for UTIME_NOW/OMIT
  - Move qemu_utimensat() to cutils.c
V2:
  - Introduce qemu_utimensat()

Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
---
 cutils.c             |   43 +++++++++++++++++++++++++++++++++++++++++++
 hw/virtio-9p-local.c |    4 ++--
 qemu-common.h        |   10 ++++++++++
 3 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/cutils.c b/cutils.c
index 536ee93..3c18941 100644
--- a/cutils.c
+++ b/cutils.c
@@ -288,3 +288,46 @@ int fcntl_setfl(int fd, int flag)
 }
 #endif
 
+int qemu_utimensat(int dirfd, const char *path, const struct timespec *times,
+                   int flags)
+{
+#ifdef CONFIG_UTIMENSAT
+    return utimensat(dirfd, path, times, flags);
+#else
+    /* Fallback: use utimes() instead of utimensat() */
+    struct timeval tv[2], tv_now;
+    struct stat st;
+    int i;
+
+    /* happy if special cases */
+    if (times[0].tv_nsec == UTIME_OMIT && times[1].tv_nsec == UTIME_OMIT) {
+        return 0;
+    }
+    if (times[0].tv_nsec == UTIME_NOW && times[1].tv_nsec == UTIME_NOW) {
+        return utimes(path, NULL);
+    }
+
+    /* prepare for hard cases */
+    if (times[0].tv_nsec == UTIME_NOW || times[1].tv_nsec == UTIME_NOW) {
+        gettimeofday(&tv_now, NULL);
+    }
+    if (times[0].tv_nsec == UTIME_OMIT || times[1].tv_nsec == UTIME_OMIT) {
+        stat(path, &st);
+    }
+
+    for (i = 0; i < 2; i++) {
+        if (times[i].tv_nsec == UTIME_NOW) {
+            tv[i].tv_sec = tv_now.tv_sec;
+            tv[i].tv_usec = 0;
+        } else if (times[i].tv_nsec == UTIME_OMIT) {
+            tv[i].tv_sec = (i == 0) ? st.st_atime : st.st_mtime;
+            tv[i].tv_usec = 0;
+        } else {
+            tv[i].tv_sec = times[i].tv_sec;
+            tv[i].tv_usec = times[i].tv_nsec / 1000;
+        }
+    }
+
+    return utimes(path, &tv[0]);
+#endif
+}
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 0d52020..41603ea 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -480,9 +480,9 @@ static int local_chown(FsContext *fs_ctx, const char *path, FsCred *credp)
 }
 
 static int local_utimensat(FsContext *s, const char *path,
-		       const struct timespec *buf)
+                           const struct timespec *buf)
 {
-    return utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
+    return qemu_utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
 }
 
 static int local_remove(FsContext *ctx, const char *path)
diff --git a/qemu-common.h b/qemu-common.h
index 2fbc27f..7fe4c16 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -146,6 +146,16 @@ time_t mktimegm(struct tm *tm);
 int qemu_fls(int i);
 int qemu_fdatasync(int fd);
 int fcntl_setfl(int fd, int flag);
+#ifndef CONFIG_UTIMENSAT
+#ifndef UTIME_NOW
+# define UTIME_NOW     ((1l << 30) - 1l)
+#endif
+#ifndef UTIME_OMIT
+# define UTIME_OMIT    ((1l << 30) - 2l)
+#endif
+#endif
+int qemu_utimensat(int dirfd, const char *path, const struct timespec *times,
+    int flags);
 
 /* path.c */
 void init_paths(const char *prefix);
-- 
1.7.3.1

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [Qemu-devel] Re: [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT
  2010-11-15  2:15               ` [Qemu-devel] [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT Hidetoshi Seto
@ 2010-11-15  3:36                 ` Chris Wright
  2010-11-15 16:49                 ` M. Mohan Kumar
  2010-11-21 15:22                 ` [Qemu-devel] " Anthony Liguori
  2 siblings, 0 replies; 17+ messages in thread
From: Chris Wright @ 2010-11-15  3:36 UTC (permalink / raw)
  To: Hidetoshi Seto
  Cc: Blue Swirl, kvm@vger.kernel.org, Jes.Sorensen, Hao, Xudong,
	qemu-devel@nongnu.org, Chris Wright, mohan, Avi Kivity

* Hidetoshi Seto (seto.hidetoshi@jp.fujitsu.com) wrote:
> This patch introduce a fallback mechanism for old systems that do not
> support utimensat().  This fix build failure with following warnings:
> 
> hw/virtio-9p-local.c: In function 'local_utimensat':
> hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat'
> hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat'
> 
> and:
> 
> hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
> hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this function)
> hw/virtio-9p.c:1410: error: (Each undeclared identifier is reported only once
> hw/virtio-9p.c:1410: error: for each function it appears in.)
> hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this function)
> hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
> hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this function)
> 
> v3:
>   - Use better alternative handling for UTIME_NOW/OMIT
>   - Move qemu_utimensat() to cutils.c
> V2:
>   - Introduce qemu_utimensat()
> 
> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>

Looks good to me (no strong opinion on the cutils vs oslib-posix that
Jes mentioned).

Acked-by: Chris Wright <chrisw@sous-sol.org>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Qemu-devel] Re: [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT
  2010-11-15  2:15               ` [Qemu-devel] [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT Hidetoshi Seto
  2010-11-15  3:36                 ` [Qemu-devel] " Chris Wright
@ 2010-11-15 16:49                 ` M. Mohan Kumar
  2010-11-21 15:22                 ` [Qemu-devel] " Anthony Liguori
  2 siblings, 0 replies; 17+ messages in thread
From: M. Mohan Kumar @ 2010-11-15 16:49 UTC (permalink / raw)
  To: Hidetoshi Seto
  Cc: Blue Swirl, kvm@vger.kernel.org, Jes.Sorensen, Hao, Xudong,
	qemu-devel@nongnu.org, Chris Wright, Avi Kivity

> This patch introduce a fallback mechanism for old systems that do not
> support utimensat().  This fix build failure with following warnings:
> 
> hw/virtio-9p-local.c: In function 'local_utimensat':
> hw/virtio-9p-local.c:479: warning: implicit declaration of function
> 'utimensat' hw/virtio-9p-local.c:479: warning: nested extern declaration
> of 'utimensat'
> 
> and:
> 
> hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
> hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this
> function) hw/virtio-9p.c:1410: error: (Each undeclared identifier is
> reported only once hw/virtio-9p.c:1410: error: for each function it
> appears in.)
> hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this
> function) hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
> hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this
> function)
> 
> v3:
>   - Use better alternative handling for UTIME_NOW/OMIT
>   - Move qemu_utimensat() to cutils.c
> V2:
>   - Introduce qemu_utimensat()
> 
> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>

Looks good to me.

Acked-by: M. Mohan Kumar <mohan@in.ibm.com>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT
  2010-11-15  2:15               ` [Qemu-devel] [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT Hidetoshi Seto
  2010-11-15  3:36                 ` [Qemu-devel] " Chris Wright
  2010-11-15 16:49                 ` M. Mohan Kumar
@ 2010-11-21 15:22                 ` Anthony Liguori
  2010-11-22  6:28                   ` Jes Sorensen
  2 siblings, 1 reply; 17+ messages in thread
From: Anthony Liguori @ 2010-11-21 15:22 UTC (permalink / raw)
  To: Hidetoshi Seto
  Cc: Chris Wright, kvm@vger.kernel.org, Jes.Sorensen, Hao, Xudong,
	qemu-devel@nongnu.org, Blue Swirl, mohan, Avi Kivity

On 11/14/2010 08:15 PM, Hidetoshi Seto wrote:
> This patch introduce a fallback mechanism for old systems that do not
> support utimensat().  This fix build failure with following warnings:
>
> hw/virtio-9p-local.c: In function 'local_utimensat':
> hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat'
> hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat'
>
> and:
>
> hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
> hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this function)
> hw/virtio-9p.c:1410: error: (Each undeclared identifier is reported only once
> hw/virtio-9p.c:1410: error: for each function it appears in.)
> hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this function)
> hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
> hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this function)
>
> v3:
>    - Use better alternative handling for UTIME_NOW/OMIT
>    - Move qemu_utimensat() to cutils.c
> V2:
>    - Introduce qemu_utimensat()
>
> Signed-off-by: Hidetoshi Seto<seto.hidetoshi@jp.fujitsu.com>
>    

Applied.  Thanks.

Regards,

Anthony Liguori

> ---
>   cutils.c             |   43 +++++++++++++++++++++++++++++++++++++++++++
>   hw/virtio-9p-local.c |    4 ++--
>   qemu-common.h        |   10 ++++++++++
>   3 files changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/cutils.c b/cutils.c
> index 536ee93..3c18941 100644
> --- a/cutils.c
> +++ b/cutils.c
> @@ -288,3 +288,46 @@ int fcntl_setfl(int fd, int flag)
>   }
>   #endif
>
> +int qemu_utimensat(int dirfd, const char *path, const struct timespec *times,
> +                   int flags)
> +{
> +#ifdef CONFIG_UTIMENSAT
> +    return utimensat(dirfd, path, times, flags);
> +#else
> +    /* Fallback: use utimes() instead of utimensat() */
> +    struct timeval tv[2], tv_now;
> +    struct stat st;
> +    int i;
> +
> +    /* happy if special cases */
> +    if (times[0].tv_nsec == UTIME_OMIT&&  times[1].tv_nsec == UTIME_OMIT) {
> +        return 0;
> +    }
> +    if (times[0].tv_nsec == UTIME_NOW&&  times[1].tv_nsec == UTIME_NOW) {
> +        return utimes(path, NULL);
> +    }
> +
> +    /* prepare for hard cases */
> +    if (times[0].tv_nsec == UTIME_NOW || times[1].tv_nsec == UTIME_NOW) {
> +        gettimeofday(&tv_now, NULL);
> +    }
> +    if (times[0].tv_nsec == UTIME_OMIT || times[1].tv_nsec == UTIME_OMIT) {
> +        stat(path,&st);
> +    }
> +
> +    for (i = 0; i<  2; i++) {
> +        if (times[i].tv_nsec == UTIME_NOW) {
> +            tv[i].tv_sec = tv_now.tv_sec;
> +            tv[i].tv_usec = 0;
> +        } else if (times[i].tv_nsec == UTIME_OMIT) {
> +            tv[i].tv_sec = (i == 0) ? st.st_atime : st.st_mtime;
> +            tv[i].tv_usec = 0;
> +        } else {
> +            tv[i].tv_sec = times[i].tv_sec;
> +            tv[i].tv_usec = times[i].tv_nsec / 1000;
> +        }
> +    }
> +
> +    return utimes(path,&tv[0]);
> +#endif
> +}
> diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
> index 0d52020..41603ea 100644
> --- a/hw/virtio-9p-local.c
> +++ b/hw/virtio-9p-local.c
> @@ -480,9 +480,9 @@ static int local_chown(FsContext *fs_ctx, const char *path, FsCred *credp)
>   }
>
>   static int local_utimensat(FsContext *s, const char *path,
> -		       const struct timespec *buf)
> +                           const struct timespec *buf)
>   {
> -    return utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
> +    return qemu_utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
>   }
>
>   static int local_remove(FsContext *ctx, const char *path)
> diff --git a/qemu-common.h b/qemu-common.h
> index 2fbc27f..7fe4c16 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -146,6 +146,16 @@ time_t mktimegm(struct tm *tm);
>   int qemu_fls(int i);
>   int qemu_fdatasync(int fd);
>   int fcntl_setfl(int fd, int flag);
> +#ifndef CONFIG_UTIMENSAT
> +#ifndef UTIME_NOW
> +# define UTIME_NOW     ((1l<<  30) - 1l)
> +#endif
> +#ifndef UTIME_OMIT
> +# define UTIME_OMIT    ((1l<<  30) - 2l)
> +#endif
> +#endif
> +int qemu_utimensat(int dirfd, const char *path, const struct timespec *times,
> +    int flags);
>
>   /* path.c */
>   void init_paths(const char *prefix);
>    

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT
  2010-11-21 15:22                 ` [Qemu-devel] " Anthony Liguori
@ 2010-11-22  6:28                   ` Jes Sorensen
  0 siblings, 0 replies; 17+ messages in thread
From: Jes Sorensen @ 2010-11-22  6:28 UTC (permalink / raw)
  To: Anthony Liguori
  Cc: Chris Wright, Hidetoshi Seto, kvm@vger.kernel.org, Hao, Xudong,
	qemu-devel@nongnu.org, Blue Swirl, mohan, Avi Kivity

On 11/21/10 16:22, Anthony Liguori wrote:
> On 11/14/2010 08:15 PM, Hidetoshi Seto wrote:
>> This patch introduce a fallback mechanism for old systems that do not
>> support utimensat().  This fix build failure with following warnings:
>>
>> hw/virtio-9p-local.c: In function 'local_utimensat':
>> hw/virtio-9p-local.c:479: warning: implicit declaration of function
>> 'utimensat'
>> hw/virtio-9p-local.c:479: warning: nested extern declaration of
>> 'utimensat'
>>
>> and:
>>
>> hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
>> hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this
>> function)
>> hw/virtio-9p.c:1410: error: (Each undeclared identifier is reported
>> only once
>> hw/virtio-9p.c:1410: error: for each function it appears in.)
>> hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this
>> function)
>> hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
>> hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this
>> function)
>>
>> v3:
>>    - Use better alternative handling for UTIME_NOW/OMIT
>>    - Move qemu_utimensat() to cutils.c
>> V2:
>>    - Introduce qemu_utimensat()
>>
>> Signed-off-by: Hidetoshi Seto<seto.hidetoshi@jp.fujitsu.com>
>>    
> 
> Applied.  Thanks.
> 
> Regards,
> 
> Anthony Liguori

Anthony,

Did you actually apply this one? I don't see it in the git tree.

However if you did, that was a mistake, the qemu_utimensat() should not
have gone into cutils.c as I pointed out earlier, it is inconsistent.

Cheers,
Jes

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2010-11-22  6:30 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-12  1:52 [Qemu-devel] qemu-kvm build issue on RHEL5.1 Hao, Xudong
2010-10-13  8:00 ` Hidetoshi Seto
2010-10-13  8:13   ` Hao, Xudong
2010-10-13 19:11   ` Blue Swirl
2010-10-14  0:33     ` Hidetoshi Seto
2010-11-04 17:03       ` Chris Wright
2010-11-05  6:32         ` Hidetoshi Seto
2010-11-05  6:32         ` [Qemu-devel] [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2 Hidetoshi Seto
2010-11-08  6:44           ` M. Mohan Kumar
2010-11-12 12:33             ` Jes Sorensen
2010-11-14  5:58           ` [Qemu-devel] " Chris Wright
2010-11-15  2:10             ` Hidetoshi Seto
2010-11-15  2:15               ` [Qemu-devel] [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT Hidetoshi Seto
2010-11-15  3:36                 ` [Qemu-devel] " Chris Wright
2010-11-15 16:49                 ` M. Mohan Kumar
2010-11-21 15:22                 ` [Qemu-devel] " Anthony Liguori
2010-11-22  6:28                   ` Jes Sorensen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).