On Thu, Mar 7, 2019 at 3:43 PM Lukasz Majewski <lu...@denx.de> wrote: > > On Thu, Mar 7, 2019 at 8:53 AM Lukasz Majewski <lu...@denx.de> wrote: > > > > On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski <lu...@denx.de>
> To be more specific: > > I'm thinking of settimeofday/gettimeofday syscalls. > > In the kernel we use internally do_sys_settimeofday64() to support > clock_settime() and settimeofday() > > The internal (in-kernel) representation for those two is struct > timespec64. > > If I may ask - why settimeofday64() and gettimeofday64() are not > implemented? > > Is it because the same result can be achieved with clock_settime64(tv64) > + settimeofday(NULL, tz) ? > (The drawback is two syscalls instead of one). Yes, that is the idea. I don't see the drawback as significant here, since settimeofday() is not performance critical. > I've also stumbled upon the __kernel_timex introduction on the > playground branch: > > "time: Add struct __kernel_timex" > 2c620ff93d9fbd5d644760d4c21d389078ec1080 > > This one introduces the: > struct __kernel_timex_timeval { > __kernel_time64_t tv_sec; > long long tv_usec; > }; > > This code is "protected" by CONFIG_64BIT_TIME. > > Is there any plan to explicitly introduce: > > struct __kernel_timeval { > __kernel_time64_t tv_sec; > long ong tv_usec; > } > > and convert settimeofday()/gettimeofday() ? No, see above. Basically all system calls that take a 'timeval' already have a replacement that uses a 'timespec' with nanosecond resolution, so the idea was that by not having a new timeval, we make sure to catch any calls that need a nanosecond based version as well. clock_adjtime() is a bit of a special case here because it uses a timeval structure but passes nanoseconds in it when ADJ_NANO is set. Arnd