>>>> The series aims at isolating data conversions of time_t based structures: >>>> struct timespec and struct itimerspec at user space boundaries. >>>> This helps to later change the underlying types to handle y2038 changes >>>> to these. >>> >>> Nice... A few questions: >>> >>> * what about setitimer(2)? Right now that's the only remaining user of >>> get_compat_itimerval(); similar for getitimer(2) and put_compat_itimerval(). >> >> We do not plan to support these beyond y2038 on 32 bit systems. >> timer_settime() and timer_gettime() are considered to be replacements >> for these, respectively. >> >> There is also going to be a cleanup of timeval/ timespec/ time_t data >> types and apis after the new syscalls are ready. >> At that time I might choose to get rid of these itimerval apis. I'm >> not sure yet. > > I see that internally, alarm/getitimer/setitimer all use ktime_t, so > one possible solution would be to push down the use of ktime_t > into the callers and do both the conversion and range check in the > user copy function. Right. This is one way of doing it. I was asking if you guys are okay with doing this as a cleanup series later or would you like for it to be part of the current series? -Deepa
