On 30/05/20 10:40 +0200, Mark Kettenis wrote: > > Date: Sat, 30 May 2020 10:32:15 +0200 > > From: Robert Nagy <[email protected]> > > > > 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 <[email protected]> > > > > > > > > > > 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?
