Messages in this thread | | | Date | Thu, 7 Mar 2019 15:43:10 +0100 | From | Lukasz Majewski <> | Subject | Re: [Y2038] Question regarding support of old time interfaces beyond y2038 |
| |
Hi Arnd,
> On Thu, Mar 7, 2019 at 8:53 AM Lukasz Majewski <lukma@denx.de> wrote: > > > > Hi Zack, > > > > > On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski <lukma@denx.de> > > > wrote: > > > > From other discussion [4] - regarding the following system > > > > calls: time, stime, gettimeofday, settimeofday, adjtimex, > > > > nanosleep, alarm, getitimer, setitimer, select, utime, utimes, > > > > futimesat, and {old,new}{l,f,}stat{,64}. > > > > > > > > "These all pass 32-bit time_t arguments on 32-bit > > > > architectures and are replaced by other interfaces (e.g. posix > > > > timers and clocks, statx). C libraries implementing 64-bit > > > > time_t in 32-bit architectures have to implement the handles by > > > > wrapping around the newer interfaces." > > > > > > 1) We should be clear that most of these will continue to be > > > supported as C library interfaces even if they are not system > > > calls. Some of them are obsolete enough and/or rarely used > > > enough that we might not bother (the older ways to set the system > > > clock, for instance). > > > > The question here is about the decision if even the old time APIs > > shall be supported on 32 bit systems which are going to be Y2038 > > proof (like the 'stime'). > > See my other reply. In the kernel, it won't be supported (the old > syscall is of course still there, but we may have an option to remove > all time32 interfaces).
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).
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() ?
Thanks in advance for your help.
> In glibc, it's probably there in a y2038-safe > way since it is there now, other C libraries may take other decisions > that are independent of y2038. > > Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de [unhandled content-type:application/pgp-signature] | |