> From: Paul Irofti <p...@irofti.net>
> Date: Sat, 30 May 2020 13:53:18 +0300
>
> 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
Yes, that would be better.
