Mark Kettenis <mark.kette...@xs4all.nl> wrote: > 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.
I agree. The alternative being tried here is to do it all at link-time. I don't think that is flexible enough to cover all the architectures. Determining this at startup, and following a pointer is the natural approach. (There has been some pressure to get this in before it covers all the architectures and this kind of discussion is why I think such a premature "and then we'll fix it in the tree" procedure is wrong).
