From mboxrd@z Thu Jan  1 00:00:00 1970
From: Don Slutz <dslutz@verizon.com>
Subject: Re: [PATCH v3 5/5] xen/console: Traditional console
 timestamps including milliseconds
Date: Fri, 07 Mar 2014 18:33:16 -0500
Message-ID: <531A573C.6050807@terremark.com>
References: <1394134085-22952-1-git-send-email-andrew.cooper3@citrix.com>
	<1394134085-22952-6-git-send-email-andrew.cooper3@citrix.com>
	<53190AB0.4020806@terremark.com> <531915C4.6060102@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <531915C4.6060102@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>, Don Slutz <dslutz@verizon.com>, Xen-devel <xen-devel@lists.xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>, Jan Beulich <JBeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

On 03/06/14 19:41, Andrew Cooper wrote:
> On 06/03/2014 23:54, Don Slutz wrote:
>> On 03/06/14 14:28, Andrew Cooper wrote:
>>>    }
>>>    -struct tm wallclock_time(void)
>>> +struct tm wallclock_time(uint64_t *ns)
>>>    {
>> Adding:
>>
>>     if ( ns )
>>        *ns = 0;
>>
>> Makes sense here.
>>
>>>        return (struct tm) { 0 };
>>>    }
>>> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
>>> index 4f4de22..1156ccc 100644
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -1646,15 +1646,19 @@ int dom0_pit_access(struct ioreq *ioreq)
>>>        return 0;
>>>    }
>>>    -struct tm wallclock_time(void)
>>> +struct tm wallclock_time(uint64_t *ns)
>>>    {
>>> -    uint64_t seconds;
>>> +    uint64_t seconds, nsec;
>>>          if ( !wc_sec )
>> And here.
>>
>>>            return (struct tm) { 0 };
>>>          seconds = NOW() + SECONDS(wc_sec) + wc_nsec;
>>> -    do_div(seconds, 1000000000);
>>> +    nsec = do_div(seconds, 1000000000);
>>> +
>>> +    if ( *ns )
>> This should be just
>>
>>     if ( ns )
> Oops - so it should.
>
> As for the other changes, I am a bit ambivalent.  printk_start_of_line()
> is the sole caller of wallclock_time(), which means that tm.tm_day being
> 0 means *ns will never get looked at.

This is not 100% true.  Last I knew (struct tm) { 0 } is

struct tm {
     int     tm_sec;         /* seconds */ = 0
     int     tm_min;         /* minutes */ <undef>
     int     tm_hour;        /* hours */ <undef>
     int     tm_mday;        /* day of the month */ <undef>
     int     tm_mon;         /* month */ <undef>
     int     tm_year;        /* year */ <undef>
     int     tm_wday;        /* day of the week */ <undef>
     int     tm_yday;        /* day in the year */ <undef>
     int     tm_isdst;       /* daylight saving time */ <undef>
};

But not having looked at the code, and the compilers could have changed 
what this means (i.e. if not provided they are zero in which case this 
should be {}.  { 0, 0, 0, 0 } or { .tm_mday = 0 } is the way I know of 
to say "tm_mday" is zero).

So the test for tm.tm_mday == 0 may just be working because the 
undefined value is zero...

> While it is not exactly a hot codepath, unconditionally clearing it
> seems silly, especially as it is not exactly the most likely candidate
> to get a new caller in the near future.

There is no clear right answer here.  So I have no issue with not doing 
the "extra" work.

    -Don Slutz

> ~Andrew
>