From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14450
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: Rich Felker <dalias@libc.org>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Final (?) time64 proposal
Date: Thu, 25 Jul 2019 01:18:32 -0400
Message-ID: <20190725051832.GK1506@brightrain.aerifal.cx>
References: <20190724053142.GB1506@brightrain.aerifal.cx>
Reply-To: musl@lists.openwall.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
	logging-data="136741"; mail-complaints-to="usenet@blaine.gmane.org"
User-Agent: Mutt/1.5.21 (2010-09-15)
To: musl@lists.openwall.com
Original-X-From: musl-return-14466-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 25 07:18:47 2019
Return-path: <musl-return-14466-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@m.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by blaine.gmane.org with smtp (Exim 4.89)
	(envelope-from <musl-return-14466-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1hqW9P-000ZTz-Ff
	for gllmg-musl@m.gmane.org; Thu, 25 Jul 2019 07:18:47 +0200
Original-Received: (qmail 18068 invoked by uid 550); 25 Jul 2019 05:18:45 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Original-Received: (qmail 18049 invoked from network); 25 Jul 2019 05:18:44 -0000
Content-Disposition: inline
In-Reply-To: <20190724053142.GB1506@brightrain.aerifal.cx>
Original-Sender: Rich Felker <dalias@aerifal.cx>
Xref: news.gmane.org gmane.linux.lib.musl.general:14450
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/14450>

On Wed, Jul 24, 2019 at 01:31:42AM -0400, Rich Felker wrote:
> With that said, the following are the functions I've identified as
> still interfacing with the kernel in ways that involve time_t:
> 
> - clock_gettime **
> - clock_settime **
> - clock_adjtime **
> - clock_nanosleep
> - timer_gettime
> - timer_settime
> - timerfd_gettime
> - timerfd_settime
> - utimensat **
> - mq_timedsend **
> - mq_timedreceive **
> - getitimer
> - setitimer
> - select
> - pselect
> - ppoll
> - recvmmsg ?
> - sigtimedwait
> - semtimedop
> - clock_getres
> - sched_rr_get_interval
> - __timedwait (backend for all timed futex waits)
> - getrusage
> - wait4
> - wait3
> - setsockopt
> - getsockopt
> - shmctl ***
> - semctl ***
> - msgctl ***
> - ioctl
> - recvmsg ?

I think a good next-step here would be modifying all of the above to
go through an intermediate kernel-type struct when using the existing
syscalls. This should not change behavior anywhere except for a slight
increase in size/time-spent, but will set things up so that, when the
time_t definition is switched over, everything should just start
working automatically with 64-bit time. It will also let us drop the
__fixup hacks in arch/x32/syscall_arch.h and
src/thread/x32/syscall_cp_fixup.c, analogous to how commit
01ae3fc6d48f4a45535189b7a6db286535af08ca let us drop the corresponding
mips hacks.

Rich