From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12426 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getcontext, setcontext, makecontext and swapcontext Date: Mon, 29 Jan 2018 13:47:55 -0500 Message-ID: <20180129184755.GL1627@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 1517251591 7097 195.159.176.226 (29 Jan 2018 18:46:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Jan 2018 18:46:31 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12442-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 29 19:46:27 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 1egERZ-0000bh-E1 for gllmg-musl@m.gmane.org; Mon, 29 Jan 2018 19:46:13 +0100 Original-Received: (qmail 10110 invoked by uid 550); 29 Jan 2018 18:48:08 -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 10084 invoked from network); 29 Jan 2018 18:48:07 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12426 Archived-At: On Sun, Jan 28, 2018 at 01:24:58PM +0100, Tmp File wrote: > Hello all. > > I'm compiling many software in a musl box and (by far) the biggest > wall I hit regards the functions getcontext, setcontext, makecontext > and swapcontext. I understand they are deprecated, but they are used > in many programs and it's usually really troublesome/tricky to > modify the upstream source code to accomodate for them being > unavailable on musl. > > David du Colombier from plan9port mentioned[0] a simple coroutine library called libstak[1] that should help. > I see 2 possible approaches: > (i) musl imports libstak > (ii} users somehow compile libstak and make it available for programs that need the *context functions > > In case you aren't interested in (i) could somebody help us get (ii) to work? > Then musl distros like Alpine could have libstak as some kind of "compatibility" layer. > Of course (i) might be a better solution, if you aren't so concerned about getcontext, setcontext, makecontext and swapcontext "deprecation status". I know this can sound frustrating, but the reason the ucontext functions are not include (yet? maybe they will be) is not simply missing implementations for the archs we support (which raises the question: does libstak actually support all the archs we support?) but the maintenance and new-arch-porting cost of having to provide these interfaces, relative to their value. They're all delicate stuff that's easy to get subtly wrong, and quite a large amount of work to write compared to the existing, super-tiny amount of asm it takes to port musl to a new arch. They also may be difficult or impossible to support for new targets -- things like wasm or pnacl. Even if policy and namespace conformance issues allowed pulling in third-party libraries, the maintenance effort and complexity of doing that would greatly outweigh the effort of just writing these functions for the archs we support (or copying implementations with compatible license). But the big issue is how choices like this affect future requirements on musl, not immediate work right now. Supporting dubious nonstandard and deprecated interfaces has gotten us in big trouble in the past -- see the malloc_usable_size issue. I'm not sure yet what the right way forward is. One clean option, since the ucontext functions don't really have significant (any?) interaction with libc stuff, is just using a separate third-party library when linking programs that need them. Alternatively, at some point we may add them to libc. This would probably make the most sense if (1) it really turns out to be impossible to extricate some key software from them, and (2) there end up being reasons they do need to interact with libc somehow. Rich