From: Lukasz Majewski <lukma@denx.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Zack Weinberg <zackw@panix.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Joseph Myers <joseph@codesourcery.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [Y2038] Question regarding support of old time interfaces beyond y2038
Date: Thu, 7 Mar 2019 15:43:10 +0100 [thread overview]
Message-ID: <20190307154310.677b59dd@jawa> (raw)
In-Reply-To: <CAK8P3a3GotM4WY9dJK8yPujxLgHXtnes=nMUKq5fJ4hTkZWqzg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-03-07 14:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 15:23 [Y2038] Question regarding support of old time interfaces beyond y2038 Lukasz Majewski
2019-03-05 16:05 ` Zack Weinberg
2019-03-05 16:56 ` Ben Hutchings
2019-03-07 7:53 ` Lukasz Majewski
2019-03-07 8:05 ` Arnd Bergmann
2019-03-07 14:43 ` Lukasz Majewski [this message]
2019-03-07 15:26 ` Arnd Bergmann
2019-03-07 19:20 ` Joseph Myers
2019-03-05 17:04 ` Arnd Bergmann
2019-03-07 7:47 ` Lukasz Majewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190307154310.677b59dd@jawa \
--to=lukma@denx.de \
--cc=arnd@arndb.de \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zackw@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.