On Mon, Jan 04, 2021 at 06:20:52PM -0800, Joelle van Dyne wrote: > iOS does not support ucontext natively for aarch64 and the sigaltstack is > also unsupported (even worse, it fails silently, see: > https://openradar.appspot.com/13002712 ) > > As a workaround we include a library implementation of ucontext and add it > as a build option. > > Signed-off-by: Joelle van Dyne <j...@getutm.app> > --- > configure | 23 ++++++++++++++++++++--- > meson.build | 11 ++++++++++- > util/coroutine-ucontext.c | 9 +++++++++ > .gitmodules | 3 +++ > meson_options.txt | 2 ++ > subprojects/libucontext | 1 + > 6 files changed, 45 insertions(+), 4 deletions(-) > create mode 160000 subprojects/libucontext
> diff --git a/.gitmodules b/.gitmodules > index 2bdeeacef8..4f02eed79a 100644 > --- a/.gitmodules > +++ b/.gitmodules > @@ -64,3 +64,6 @@ > [submodule "roms/vbootrom"] > path = roms/vbootrom > url = https://git.qemu.org/git/vbootrom.git > +[submodule "libucontext"] > + path = subprojects/libucontext > + url = https://github.com/utmapp/libucontext.git Using libucontext looks like a good idea to me, but I noticed that this is a pointing to a fork of the main libucontext project at https://github.com/kaniini/libucontext The main project appears 100's of commits ahead of the utmapp fork What is in the utmapp fork that isn't present in the primary libucontext repo ? I think if we're going to use libucontext we will want to point to the primary project, and this means anything custom in the fork will need to get submitted upstream. Maybe you've already started doing that making this a non-issue ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
