On 2020-05-30 12:40, Mark Kettenis wrote:
Date: Sat, 30 May 2020 10:49:07 +0200
From: Robert Nagy <rob...@openbsd.org>
On 30/05/20 10:40 +0200, Mark Kettenis wrote:
Date: Sat, 30 May 2020 10:32:15 +0200
From: Robert Nagy <rob...@openbsd.org>
On 29/05/20 17:51 +0300, Paul Irofti wrote:
On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
Date: Fri, 29 May 2020 13:45:37 +0100
From: Stuart Henderson <s...@spacehopper.org>
On 2020/05/29 13:50, Paul Irofti wrote:
+struct __timekeep {
+ uint32_t major; /* version major number */
+ uint32_t minor; /* version minor number */
+
+ u_int64_t th_scale;
+ unsigned int th_offset_count;
+ struct bintime th_offset;
+ struct bintime th_naptime;
+ struct bintime th_boottime;
+ volatile unsigned int th_generation;
+
+ unsigned int tc_user;
+ unsigned int tc_counter_mask;
+};
Ah good, you got rid of u_int, that was causing problems with port builds.
That in itself is a problem. This means <time.h> is the wrong place
for this struct. We need to find a better place for this.
Since this is now closely linked to the timecounter stuff
<sys/timetc.h> would be an obvious place. Now that file has:
#ifndef _KERNEL
#error "no user-serviceable parts inside"
#endif
you could change that into
#if !defined(_KERNEL) && !defined(_LIBC)
#error "no user-serviceable parts inside"
#endif
and make sure you #define _LIBC brefore uncluding this file where it
is needed. As few places as possible obviously.
Done. Also includes claudio@'s observation.
I think if there are no more header changes, this should be commited to
have wider testing. We are also just after tree unlock so it feels like
the right time, and since there is no library bump we can easily revert
if there is a need for that.
Not ready yet.
I also would like to see at least one non-amd64 platform supported
before we settle on this approach.
Which one would you prefer? arm64?
yes, arm64 would be good; I can probably give it a go later this weekend
I was thinking we could have a common name for the MD (arch) files. In
my diff it is rdtsc.c, but I think we can switch to have all the arches
have a file named usertc.c. What do you think?
arch/amd64/gen/rdtsc.c -> arch/amd64/gen/usertc.c
Paul, do you have some sort of regression test for this stuff?
If you use the minor bump you can switch between libc's easily and
that's what I do now. My main regress test is Firefox.
I also have a few hand written smoke tests that I wrote in the beginning
with which I test with when I do major changes. I placed them on
cvs:~pirofti/timekeep/.
Another batch that I run is the posixtestsuite (that is available as a
package now). Example:
/usr/local/libexec/posixtestsuite/conformance/interfaces/clock_gettime/1-1.test
