From: ebiederm@xmission.com (Eric W. Biederman)
To: drepper@cygnus.com (Ulrich Drepper)
Cc: Andi Kleen <ak@suse.de>, Alex Larsson <alexl@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Finegrained a/c/mtime was Re: Directory notification problem
Date: 03 Oct 2001 07:35:46 -0600 [thread overview]
Message-ID: <m1k7yc3ky5.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.33.0110022206100.29931-100000@devserv.devel.redhat.com.suse.lists.linux.kernel> <oupitdx9n2m.fsf@pigdrop.muc.suse.de> <m3r8slywp0.fsf@myware.mynet>
In-Reply-To: <m3r8slywp0.fsf@myware.mynet>
Ulrich Drepper <drepper@redhat.com> writes:
> Andi Kleen <ak@suse.de> writes:
>
> > For stat is also requires a changed glibc ABI -- the glibc/2.4 stat64
>
> Not only stat64, also plain stat.
>
> > structure reserved an additional 4 bytes for every timestamp, but these
> > either need to be used to give more seconds for the year 2038 problem
> > or be used for the ms fractions. y2038 is somewhat important too.
>
> The fields are meant for nanoseconds. The y2038 will definitely be
> solved by time-shifting or making time_t unsigned. In any way nothing
> of importance here and now. Especially since there won't be many
> systems which are running today and which have a 32-bit time_t be used
> then. For the rest I'm sure that in 37 years there will be the one or
> the other ABI change.
Right. Given current uptimes and being optimistic the fix for y2038
is probably needed by 2030 or just a little later. But in any case
64 bit systems should be maxing out by then, and the conversion to 128
bit systems should have already happened on the server side. 32 bit
systems will likely be limited to embedded and legacy systems by then.
Eric
next prev parent reply other threads:[~2001-10-03 13:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33.0110022206100.29931-100000@devserv.devel.redhat.com.suse.lists.linux.kernel>
2001-10-03 7:53 ` Finegrained a/c/mtime was Re: Directory notification problem Andi Kleen
2001-10-03 8:06 ` Ulrich Drepper
2001-10-03 13:35 ` Eric W. Biederman [this message]
2001-10-03 14:11 ` Netfilter problem Kirill Ratkin
2001-10-03 21:42 ` Luigi Genoni
2001-10-03 15:24 ` Finegrained a/c/mtime was Re: Directory notification problem Gerhard Mack
2001-10-16 18:56 ` Riley Williams
2001-10-03 15:15 ` Alex Larsson
2001-10-03 21:26 ` Andi Kleen
2001-10-05 12:44 ` Padraig Brady
2001-10-05 12:59 ` Andrew Pimlott
2001-10-05 13:01 ` Andi Kleen
2001-10-05 13:15 ` Padraig Brady
2001-10-05 14:38 ` Andi Kleen
2001-10-05 15:00 ` Padraig Brady
2001-10-05 19:12 ` Andi Kleen
2001-10-08 8:39 ` Padraig Brady
2001-10-08 8:58 ` Padraig Brady
2001-10-08 10:04 ` Trond Myklebust
2001-10-05 20:22 ` Bernd Eckenfels
2001-10-03 17:45 ` Bernd Eckenfels
2001-10-13 15:24 ` Jamie Lokier
2001-10-13 16:12 ` Andi Kleen
2001-10-13 19:38 ` Jamie Lokier
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=m1k7yc3ky5.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=ak@suse.de \
--cc=alexl@redhat.com \
--cc=drepper@cygnus.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox