All of lore.kernel.org
 help / color / mirror / Atom feed
From: annie li <annie.li@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>,
	"Zhang, Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [PATCH] hvm: Correct RTC time offset update error due to tm->tm_year
Date: Wed, 22 Feb 2012 21:10:34 +0800	[thread overview]
Message-ID: <4F44E94A.2060209@oracle.com> (raw)
In-Reply-To: <1329908701.2880.26.camel@zakaz.uk.xensource.com>


Thanks a lot for your reply, Ian.
I guess there is misunderstanding here, see following,
> The Linux kernel's version of mktime and Xen's version both differ from
> standard C/POSIX defined function (in fact I expect Xen's is derived
> from Linux's). Not least because they take a bunch of values instead of
> a struct tm as arguments (i.e. they take unsigned int year, not
> tm->tm_year).
>   
Yes, Xen's is same as Linux's.
> If you wanted to compare Xen vs. a POSIX compliant mktime you'd probably
> want the libc version. The Xen and Linux mktime()s certainly differ
> substantially from the eglibc one.
>   
Thanks, my original aim is to address an issue in rtc_set_time of 
\xen\arch\x86\hvm\rtc.c. (at least I thought it was, need your 
confirmation :-) )
> I don't think you can expect that the in-kernel mktime necessarily has
> the same interface as POSIX documents, there is certainly no particular
> reason why they should or must (a kernel is not a POSIX environment).
> The comment preceding Xen's mktime makes no mention of offsetting
> anything by 1900 (or anything else) and I believe its implementation is
> consistent with its defined interface.
>   
Yes, the comments does not mention of offsetting anything by 1900, and 
this is the reason why I created the patch.
In \xen\arch\x86\hvm\rtc.c, rtc_set_time call mktime to calculate the 
seconds since 1970/01/01, the input parameters of mktime are required to 
be in normal date format. Such as: year=1980, mon=12, day=31, hour=23, 
min=59, sec=59. (Just like Linux)

However, current xen code has some problem when dealing with 
tm->tm_year, see following,
    tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]) + 100;
    after = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
                   tm->tm_hour, tm->tm_min, tm->tm_sec);
(For example, if current time is 2012/12/31, tm->tm_year is 112 here)

To meet the requirement of Xen's mktime, tm->tm_year should be changed 
to tm->tm_year+1900 when calling mktime in Xen. See following,
    after = mktime(tm->tm_year+1900, tm->tm_mon+1, tm->tm_mday,
                   tm->tm_hour, tm->tm_min, tm->tm_sec);

Thanks,
Annie
> Ian.
>
>   
>> See following diff file which is created between mktime of linux and 
>> mktime of xen, (I did some tab/space format changes for comparison)
>>
>> diff linux-mktime.c xen-mktime.c
>> 2,4c2,4
>> < mktime(const unsigned int year0, const unsigned int mon0,
>> <       const unsigned int day, const unsigned int hour,
>> <       const unsigned int min, const unsigned int sec)
>> ---
>>  > mktime (unsigned int year, unsigned int mon,
>>  >       unsigned int day, unsigned int hour,
>>  >       unsigned int min, unsigned int sec)
>> 6,8c6
>> <       unsigned int mon = mon0, year = year0;
>> <
>> <       /* 1..12 -> 11,12,1..10 */
>> ---
>>  >       /* 1..12 -> 11,12,1..10: put Feb last since it has a leap day. */
>> 10c8
>> <               mon += 12;      /* Puts Feb last since it has leap day */
>> ---
>>  >               mon += 12;
>> 21d18
>> <
>>
>> Thanks
>> Annie
>>     
>>> best regards
>>> yang
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xensource.com/xen-devel
>>>       
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xensource.com/xen-devel
>>     
>
>
>   

  reply	other threads:[~2012-02-22 13:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-20  7:19 [PATCH] hvm: Correct RTC time offset update error due to tm->tm_year ANNIE LI
2012-02-20 14:53 ` Zhang, Yang Z
2012-02-20 15:04   ` young zhang
2012-02-20 23:54     ` Zhang, Yang Z
2012-02-21  2:31       ` ANNIE LI
2012-02-22 11:05         ` Ian Campbell
2012-02-22 13:10           ` annie li [this message]
2012-02-22 13:58             ` Ian Campbell
2012-02-22 14:35               ` annie li
2012-02-23 14:52               ` annie li
2012-02-23 15:17                 ` annie li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F44E94A.2060209@oracle.com \
    --to=annie.li@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Kurt.Hackel@oracle.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=yang.z.zhang@intel.com \
    --cc=young.zhang.free@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.