> 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
Paul, do you have some sort of regression test for this stuff?
