From mboxrd@z Thu Jan  1 00:00:00 1970
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: [kvm-unit-tests PATCH] powerpc: Add tests for RTAS
Date: Thu, 3 Mar 2016 18:09:13 +0100
Message-ID: <20160303170912.GD2354@potion.brq.redhat.com>
References: <1457008099-29944-1-git-send-email-lvivier@redhat.com>
 <20160303160309.GC2354@potion.brq.redhat.com>
 <56D8666A.40508@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Laurent Vivier <lvivier@redhat.com>, kvm@vger.kernel.org,
	kvm-ppc@vger.kernel.org, drjones@redhat.com, thuth@redhat.com,
	dgibson@redhat.com
To: Paolo Bonzini <pbonzini@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:51440 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754426AbcCCRJR (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 3 Mar 2016 12:09:17 -0500
Content-Disposition: inline
In-Reply-To: <56D8666A.40508@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

2016-03-03 17:29+0100, Paolo Bonzini:
> On 03/03/2016 17:03, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote:
>>> > diff --git a/powerpc/rtas.c b/powerpc/rtas.c
>>> > +#define DAYS(y,m,d) (365UL * (y) + ((y) / 4) - ((y) / 100) + ((y=
) / 400) + \
>>> > +		     367UL * (m) / 12  + \
>>> > +		     (d))
>> This function is hard to (re)use.
>> What about putting the "month -=3D 2" block together with DAYS to gi=
ve a
>> better estimate of the amount of days in the gregorian calendar?
>=20
> Even the Gregorian calendar only starts in 1583 though. :)
>=20
> This is just a utility function for mktime.  I think it's okay.  We
> should aim at making libcflat a minimal libc, and in that case we wou=
ld
> move mktime to lib/.  Putting stuff directly in tests is good enough
> (worse is better), but let's remember that duplicated code is not.

I agree that there is no need to move stuff into lib/.
I just wouldn't expose DAYS in this shape even to mktime, because DAYS
makes little sense without the "month -=3D 2" fixup.

>>> > +	/* Put February at end of the year to avoid leap day this year =
*/

Leap day is not the only reason.
'367UL * (m) / 12' equation needs to have shifted months to report the
correct numbers of days throughout any year.

>>> > +	/* compute epoch: substract DAYS(since_March(1-1-1970)) */
>>> > +	epoch =3D DAYS(year, month, day) - DAYS(1969, 11, 1);

And this comment points out that the API is bad. :)

(Btw. am I going overboard?)