[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180129184755.GL1627@brightrain.aerifal.cx>
Date: Mon, 29 Jan 2018 13:47:55 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: getcontext, setcontext, makecontext and swapcontext
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
