On 05.06.2020 20:25, Mark Kettenis wrote:
Date: Fri, 5 Jun 2020 01:33:16 +0300
From: Paul Irofti <p...@irofti.net>
On Wed, Jun 03, 2020 at 05:13:42PM +0300, Paul Irofti wrote:
On 2020-05-31 20:46, Mark Kettenis 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.
I am sorry, but the more I try to implement this in a sane way, the more
obvious it is that it is not possible. I would rather have a define sausage
than something like this.
I will try to think of something else that avoids the defines, but I do not
think that your proposal is a valid solution.
OK. I think I found an elegant way around this using the Makefile
system: if usertc.c is not present in the arch/${MACHINE}/gen, then a
stub gen/usertc.c file is built that just sets the function pointer to
NULL. This avoids the need for the define checks in dlfcn/init.c and I
think fixes the rest of the issues discussed around this bit.
Also included in the diff are a few other fixes and regression tests.
I left the rdtsc and acpihpet example (with no functional acpihpet
support) just to show-case how we can handle multiple clocks on
architectures that have them.
You're still using tk_user unconditionally. If the kernel returns a
tk_user value that is larger than what's supported by libc you have an
out-of-bounds array access.
Also if the machine switches to a timecounter that has tk_user == 0
you have an out-of-bounds array access. If that happens you need to
detect this and fall back on the system call.
Right. Even though we test in the beginning for tk_user=0 it might
change until the access to tc_get_timecount(). I will fix this in my
next diff. Thanks!
