From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14142 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 00/11] Update for linux v5.1 Date: Wed, 22 May 2019 11:41:43 +0200 Message-ID: <20190522094143.GI16415@port70.net> References: <20190511164615.GA16415@port70.net> <20190512001739.GK23599@brightrain.aerifal.cx> <20190512145324.GB16415@port70.net> <20190521231147.GD23599@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="17962"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14158-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 22 11:41:59 2019 Return-path: 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 ) id 1hTNl0-0004Yf-TP for gllmg-musl@m.gmane.org; Wed, 22 May 2019 11:41:58 +0200 Original-Received: (qmail 13554 invoked by uid 550); 22 May 2019 09:41:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13533 invoked from network); 22 May 2019 09:41:55 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190521231147.GD23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14142 Archived-At: * Rich Felker [2019-05-21 19:11:47 -0400]: > On Sun, May 12, 2019 at 04:53:24PM +0200, Szabolcs Nagy wrote: > > From f6cc4cdf345d1785659ed9b59f3a2827c3fd3c53 Mon Sep 17 00:00:00 2001 > > From: Szabolcs Nagy > > Date: Thu, 9 May 2019 19:20:17 +0000 > > Subject: [PATCH 06/11] sys/socket.h: add new SO_ definitions from linux v5.1 > > > > the new definitions are from commits > > > > linux commit a9beb86ae6e55bd92f38453c8623de60b8e5a308 > > sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW > > > > linux commit 45bdc66159d49bfc7f75fe02d25bc74f5d2660cf > > socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes > > > > linux commit 9718475e69084de15c3930ce35672a7dc6da866b > > socket: Add SO_TIMESTAMPING_NEW > > > > linux commit 887feae36aee6c08e0dafcdaa5ba921abbb2c56b > > socket: Add SO_TIMESTAMP[NS]_NEW > > > > linux commit 7f1bc6e95d7840d4305595b3e4025cddda88cee5 > > sockopt: Rename SO_TIMESTAMP* to SO_TIMESTAMP*_OLD > > > > linux commit f5dd3d0c9638a9d9a02b5964c4ad636f06cf7e2c > > net: introduce SO_BINDTOIFINDEX sockopt > > > > SO_BINDTOIFINDEX behaves similar to SO_BINDTODEVICE, but takes a > > network interface index as argument, rather than the network > > interface name. > > > > _NEW socket options got introduced for 64bit time_t support on 32bit > > targets, in musl the affected socket options are always the same as > > the _OLD values since different time_t requires a new abi, so the > > _OLD vs _NEW dispatch logic was not copied from the uapi headers. > > Are the _OLD and _NEW ones intended to be application-facing APIs? I > think this is a question both of the kernel's intent and our intent. > When we add 64-bit time_t, however we do it, we'll need to emulate the > _NEW version on old kernels that lack it, and it's not clear that we'd > want to expose the _OLD version at all. > > Perhaps we should split this patch into the time64 stuff and the other > changes so that the other changes can be applied right away if there's > further discussion to be had about time64. ok i can split this. i think the intent is that the public api is SO_FOO, the kernel defines SO_FOO_OLD and SO_FOO_NEW for the old and new time_t abi respectively and then SO_FOO is defined using those like #define SO_FOO (sizeof(long)==4 && sizeof(time_t)==8 ? SO_FOO_NEW : SO_FOO_OLD) or similar, since on glibc the abi is based on feature test macros, but for us SO_FOO is always SO_FOO_OLD so it seemed simplest to just introduce the _OLD, _NEW names and leave the SO_FOO definitions alone. (i'm not sure what SO_FOO_NEW means on 64bit targets where time_t is already 64bit) > > From 01dcbc761ace09ddc7295e14f33d95bc32a15318 Mon Sep 17 00:00:00 2001 > > From: Szabolcs Nagy > > Date: Thu, 9 May 2019 22:49:28 +0000 > > Subject: [PATCH 10/11] ipc: prefer SYS_ipc when it is defined > > > > Linux v5.1 introduced ipc syscalls on targets where previously only > > SYS_ipc was available, change the logic such that the ipc code keeps > > using SYS_ipc which works backward compatibly on older kernels. > > I think this patch changes behavior at least on microblaze, which > already had both. A casual grep of arch/*/bits/syscall.h.in for > __NR_ipc and __NR_semget suggests there are no others affected, so > perhaps it's no big deal. Thoughts? i didnt notice that, i guess microblaze works either way. it's also possible to change to the new calls and fall back to SYS_ipc when that's available, however i think semtimedop will only have 64bit time_t variant on 32bit targets and IPC_64 should not be passed explicitly to the new syscalls, so dealing with those seemed to be messy.