* [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).