Check the stuff already in tip/timers/core; at the very least it overlaps considerably with your series. And your variant is a lot more convoluted - there's no need to have a separate compat restart, etc.
Thanks, I see there were updates last week to the tree.
For the nanosleep part, I see that you guys addressed the problem differently.
These were my thoughts when I did the patch.
1. I wanted to maintain a strict layering approach i.e., I wanted all the syscall and restart syscalls to be handled from k_clock layer. This means instead of each timer having to fill in its own restart function, isn't it better for the behaviour to be mandated at posix timers layer? Also, this way we can keep track of all the return values from the internal layers and process them all the same way.
2. The new type argument to the restart_block for timespec will be superfluous after year 2038 as compat_timespec is not longer relevant then. We can actually do away with it at that time. And, in the meanwhile, there will be 2 compat versions for 64 bit time_t which will be same as native format and the 32 bit format. Although this can handled because the 64 bit time_t compat and native syscalls have same entry, it seems like we are adding a field for just backward compatibility, just like the compat_timespec that is already in the struct.
3. I was also aiming for user pointers to be not touched by timer specific code as it can get messy if not handled properly with 2 compat time_t versions.
Do you guys see any benefit in doing it the way patch 4/8 in the current series does?