On Fri, Feb 5, 2016 at 5:56 PM, Andrew Morton <[email protected]> wrote: > On Fri, 5 Feb 2016 16:51:02 -0800 John Stultz <[email protected]> wrote: >> Alternatively, with the /proc/pid/timerslack_ns interface I'm working >> on, we can make the backing storage a long long and support 64bits of >> nanoseconds on all architectures. (But again, we can't really change >> PR_SET/GET_TIMERSLACK, so 32bit systems might see strange values from >> that with larger then uint slack values). >> >> Or I can just leave it as ULONG_MAX on all interfaces. >> >> Thoughts or preferences? > > /proc/<pid>/timer_slack_us?
So the issue isn't so much in the new interface (we can have it take a long long), but really in the existing PR_GET/SET_TIMERSLACK. I'm just trying to figure out if following the existing oddness is the best approach, or if we should make the new interface do a more consistent thing, but with the result that the PR_GET_TIMERSLACK interface might return "incorrect" values (just the lower 32bits). thanks -john
