From mboxrd@z Thu Jan 1 00:00:00 1970 From: annie li Subject: Re: [PATCH] hvm: Correct RTC time offset update error due to tm->tm_year Date: Wed, 22 Feb 2012 21:10:34 +0800 Message-ID: <4F44E94A.2060209@oracle.com> References: <4F41F41F.9060601@oracle.com> <4F430201.3040208@oracle.com> <1329908701.2880.26.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1329908701.2880.26.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Dan Magenheimer , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Kurt Hackel , young zhang , "Zhang, Yang Z" List-Id: xen-devel@lists.xenproject.org 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 >> > > >