From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13114 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl on a different syscall layer? Date: Tue, 14 Aug 2018 20:45:26 -0400 Message-ID: <20180815004526.GE1878@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1534293827 27188 195.159.176.226 (15 Aug 2018 00:43:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Aug 2018 00:43:47 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Alexander Revin Original-X-From: musl-return-13130-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 15 02:43:42 2018 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.84_2) (envelope-from ) id 1fpjuT-0006qz-6E for gllmg-musl@m.gmane.org; Wed, 15 Aug 2018 02:43:37 +0200 Original-Received: (qmail 28563 invoked by uid 550); 15 Aug 2018 00:45:41 -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 28544 invoked from network); 15 Aug 2018 00:45:40 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13114 Archived-At: On Tue, Aug 14, 2018 at 01:12:56AM +0200, Alexander Revin wrote: > > On Wed, Sep 17, 2014 at 7:02 PM, wrote: > >> On Wed, Sep 17, 2014 at 01:53:46PM -0400, Rich Felker wrote: > >>> The main requirement is having equivalent functionality available. On > >>> the BSD targets I've asked BSD folks about, there's supposedly no > >>> equivalent of futex except inthe Linux compat layer, which is pretty > >>> much a show-stopper unless/until it can be remedied. clone is a big > >>> unknown to me too. The other big potential problem is if the native > >>> syscall API requires a stack to communicate with the kernel (one or > >>> more BSDs require this, IIRC), since at least __unmapself needs to be > >>> able to call SYS_munmap and SYS_exit without a stack. > >> > >> Oh I see. > >> > >> This means "not much to hope for" (pity but good to know). > > > I don't think NetBSD uses the stack for syscalls on any common > > architecture, maybe on some of the obscure ones, but maybe you don't > > want to support them. > > > > Adding futex support to NetBSD would be an interesting project; it is > > not in the compat layer at present either, so that is a good reason to > > add it. NetBSD is pretty friendly... > > > > Justin (justin@...bsd.org) > > Hi guys, sorry for reviving a dead thread, but do you know if things > has changed ever since? I'm asking also because it would be nice to > unify efforts of porting musl to another archs - for example, openrisc > or m68k - though there're ports for both Linux and NetBSD, libc > support is kind of scattered over large codebase. I'm not aware of anything more on the NetBSD side. Note that "syscalls using stack" is no longer a show-stopper for musl. There's a portable, albeit less efficient, version of __unmapself that switches to a shared stack protected by a lock (with the magic exit futex automatically unlocking it atomically with thread termination). But this depends on that compat functionality or equivalent. Rich