> Date: Thu, 11 Jun 2020 17:29:44 +0200 > From: Christian Weisgerber <na...@mips.inka.de> > > Paul Irofti: > > > > Paul, that tk_nclocks addition isn't useful. You need to do the > > > bounds checking against the number of clocks you have implemented in > > > libc. How many clocks the kernel has implemented doesn't matter. > > > > What you are saying is that we could be in a situation where the kernel > > might expose 3 clocks but we only have 2 entries in libc? Why would we get > > to that point? When someone changes the clock in the kernel, that means it > > is also changed in libc. I don't think we can decouple the two parts. Right? > > But we do: make kernel; install kernel; reboot; make build. > > To cross from nclocks to nclocks+1, you need to run the new nclocks+1 > kernel with an nclocks userland. > > I keep coming back to the idea that we need an <machine/timetc.h> > header with > > #define TC_FOO 1 > #define TC_BAR 2 > #define TC_NUM 3 /* or TC_LAST or whatever */ > > Mark may have a better idea how to name this.
I think <machine/timetc.h> is fine. Architectures without exportable timecounters could just do #define TC_LAST 0 (I do think TC_LAST is a bit better for this reason).
