From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8253 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Using direct socket syscalls on x86_32 where available? Date: Fri, 31 Jul 2015 23:47:46 -0400 Message-ID: <20150801034746.GG16376@brightrain.aerifal.cx> References: <20150801000251.GF16376@brightrain.aerifal.cx> <1626944823.15072.1438399928448.JavaMail.yahoo@mail.yahoo.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1438400887 23298 80.91.229.3 (1 Aug 2015 03:48:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Aug 2015 03:48:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8266-gllmg-musl=m.gmane.org@lists.openwall.com Sat Aug 01 05:48:03 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZLNmC-0004qT-UN for gllmg-musl@m.gmane.org; Sat, 01 Aug 2015 05:48:01 +0200 Original-Received: (qmail 25648 invoked by uid 550); 1 Aug 2015 03:47:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25630 invoked from network); 1 Aug 2015 03:47:58 -0000 Content-Disposition: inline In-Reply-To: <1626944823.15072.1438399928448.JavaMail.yahoo@mail.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8253 Archived-At: On Sat, Aug 01, 2015 at 03:32:08AM +0000, Brad Conroy wrote: > > On Fri, Jul 31, 2015 at 11:13:54PM +0000, Brad Conroy wrote: > > > On 29 July 2015 at 19:32, Andy Lutomirski wrote: > > > > On Wed, Jul 29, 2015 at 5:51 AM, Justin Cormack > > > > wrote: > > > >> On 28 July 2015 at 08:44, Alexander Larsson wrote: > > > >>> On Tue, Jul 28, 2015 at 1:56 AM, Andy Lutomirski wrote: > > > >>>> > > > >>>> One way to implement it would be to favor the new syscalls but to set some > > > >>>> variable the first time one of them returns ENOSYS. Once that happens, > > > >>>> either all of them could fall back to socketcall or just that one syscall > > > >>>> could. > > > > > > > > > I've had (DRY) concerns over including a copy of unistd.h for each arch. > > > If musl used system linux include headers, this could be an ifdef. > > > > > > #include > > > #ifdef __NR_something > > > //use syscall > > > #else > > > //use socketcall > > > #endif > > > > I don't follow. This is roughly what we do and it does not solve the > > problem because it assumes that the choice is constant for a given > > arch, whereas the proposal is adding alternative syscalls that are > > conditionally available dependent on kernel version. Supporting this > > would require more complex logic for which to use and runtime fallback > > code. > > AFAICT musl uses its own arch specific __NR_* definitions > http://git.musl-libc.org/cgit/musl/tree/arch/i386/bits/syscall.h > http://git.musl-libc.org/cgit/musl/tree/arch/arm/bits/syscall.h > etc... > > If you replace those with , you will get the same defs > except that: > if the sytem kernel is newer you will have additional syscalls > if the kernel is older you won't have some that are needed for functions > > Using system definitions will ensure the system supports the defined syscalls. > This will provide an automatic path for future architectures to do the same. > > It looks like the current method allows musl to be built with syscalls that > may not even be supported by the (older) system kernel and then try to make > non-existent syscalls during runtime (rfkill comes to mind) Having behavior that depends on the kernel which was present at the time libc was built is utterly broken. In this specific case, you would end up with a libc that cannot run on older kernels. In other cases you would end up with a broken libc that's missing important functionality just because it happened to be built on a system with old kernel (headers). Neither of these is at all desirable. Generally musl supports any kernel >= 2.6.twenty-something (I'd have to check the exact version) fully, except for Linux-specific features added later which fail gracefully at runtime with ENOSYS or similar. Earlier kernels also work somewhat, theoretically back to 2.4.0 on some archs, but with degraded functionality and conformance (in particular, threads won't/can't work on pre-2.6 kernels). I can't see any reason why one would want to exchange this intentional broad compatibility for binaries that only work on particular kernel versions matching some particular build-time configuration. Rich