> From: "Theo de Raadt" <dera...@openbsd.org>
> Date: Fri, 29 May 2020 07:26:50 -0600
>
> Paul Irofti <p...@irofti.net> wrote:
>
> > On 2020-05-29 16:00, 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.
> >
> > Hmmm... so this would make it libc bound. I don't see anything wrong
> > with it, but is it what we want?
>
> what a strange comment
>
> in our world, libc (and subjuncts crt0 and ld.so) are THE ONLY valid
> interfaces to the kernel
>
> Another place to put it is in elf, since it is tied to a new elf marker.
The timekeep page isn't really tied to ELF; it's just used as a
mechanism to communicate the address of the page. Paul could have
chosen a different mechanism such as sysctl (see vm.psstrings).
> Tremendous caution is required, these include files must not reference
> each other in a way that requires excessive #include which will break
> public software
Right, that is why <sys/timetc.h> is safe. It currently produces an
error if you include it from userland.
