Paul Irofti <p...@irofti.net> wrote: > > Forget about all that for a moment. Here is an alternative suggestion: > > > > On sparc64 we need to support both tick_timecounter and > > sys_tick_timecounter. So we need some sort of clockid value to > > distnguish between those two. I already suggested to use the tc_user > > field of the timecounter for that. 0 means that a timecounter is not > > usable in userland, a (small) positive integer means a specific > > timecounter type. The code in libc will need to know whether a > > particular timecounter type can be supported. My proposal would be to > > implement a function *on all architecture* that takes the clockid as > > an argument and returns a pointer to the function that implements > > support for that timecounter. On architectures without support, ir > > when called with a clockid that isn't supported, that function would > > simply return NULL. > > Sure. All architectures will register their clocks with a unique ID in > timetc.h, right? And then we do clockfun[clockid]() in libc, right?
No, don't do that on every call -- instead, get the function pointer once.
