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 a simple coroutine library called libstak 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.