From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Subject: Re: [Qemu-devel] Re: [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT
 v2
Date: Mon, 15 Nov 2010 11:10:37 +0900
Message-ID: <4CE0969D.5070703@jp.fujitsu.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E1AC3EFA17E@shsmsx502.ccr.corp.intel.com>	<4CB56715.7080605@jp.fujitsu.com>	<AANLkTin2nTQ2W=URcpjkrjGtHMzYfdftacwKxb+qdoSx@mail.gmail.com>	<4CB64FF6.5080906@jp.fujitsu.com>	<20101104170303.GE15211@sequoia.sous-sol.org>	<4CD3A513.2010102@jp.fujitsu.com> <20101114055822.GE25164@sequoia.sous-sol.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Blue Swirl <blauwirbel@gmail.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>, mohan@in.ibm.com,
	Jes.Sorensen@redhat.com
To: Chris Wright <chrisw@sous-sol.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]:33257 "EHLO
	fgwmail7.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932416Ab0KOCLO (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 14 Nov 2010 21:11:14 -0500
Received: from m2.gw.fujitsu.co.jp ([10.0.50.72])
	by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id oAF2BDeg010340
	for <kvm@vger.kernel.org> (envelope-from seto.hidetoshi@jp.fujitsu.com);
	Mon, 15 Nov 2010 11:11:13 +0900
Received: from smail (m2 [127.0.0.1])
	by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id D9B0B45DE55
	for <kvm@vger.kernel.org>; Mon, 15 Nov 2010 11:11:12 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92])
	by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id B89E045DE51
	for <kvm@vger.kernel.org>; Mon, 15 Nov 2010 11:11:12 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id A1C391DB8041
	for <kvm@vger.kernel.org>; Mon, 15 Nov 2010 11:11:12 +0900 (JST)
Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.249.87.105])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 5C2891DB8040
	for <kvm@vger.kernel.org>; Mon, 15 Nov 2010 11:11:12 +0900 (JST)
In-Reply-To: <20101114055822.GE25164@sequoia.sous-sol.org>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

(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