> 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.

Reply via email to