OddQuirk
This page covers some "backburner" things that are too costly, complex or experimental to be included in the roadmap. Some may happen, some will fizzle out.
It so happens that the lua interfacing is isolated and has a repeating pattern to its function mapping, avoiding more exotic integration by choice. On of the reasons is that the imperative-minimal-context style lends itself well to having an additional build of the lua- compilation unit that, instead of mapping to a VM, maps to/from a serializable bytecode. This allows us to have external integration with other languages (synchronous interpretation), and to mark a subset as suitable for networked rendering, filling the role of drawing API and language binding in one.
the automated build and testing infrastructure is still rather rough and some of this will be corrected later on. for a number of good reasons (see the video below for more details) it would be useful to be able to guarantee that tool-chains running on different computers run the same output for release builds in order to avoid trusting-trust (google it) kind of issues.
31c3, reproducible builds video
primary fuzzing targets are the lua to c interface, the shmif and the arg_arr parsing for argument passing. in later stages (0.9) this would be extended to cover the c-c interface in libarcan. for the shmif and arg_arr fuzzing, we should investigate setting up cases for michal zalewskis afl-fuzz as part of tests/security. for the lua to c interface, we should investigate extending the doc/.lua files to have a field that describes data-types and generate a much simpler fuzzer for that which takes advantage of the pre-existing positive/negative examples.
the hijacking bits (interposing relevant symbols and hooking up a/v/input in common libraries) are rather stale and more of a fun concept than a serious target. these should be brought up to speed by providing means for generating libraries based on targeted symbols and which mechanism should be used for hijacking, since the pattern is so repetitive.
both osx and windows have mechanisms for passing renderbuffers between processes in the same way we are doing with drm-prime over egl, for osx we have iosurfaces and on windows it might be possible to use surface sharing along with some vendor- specific d3d-gl conversion.
among the support files in the frameserver/ part of the source tree is retexture.c. it is meant as a complicated experiment of doing dynamic programmable remapping and changes to a gl accelerated application with a hijack library. it is fairly incomplete, but can be interesting as a workaround for the lack of a ulimit- style control surface for reducing access to gpu resources.
for invalid behavior in lua scripts we have the option to provide fallback scripts that can adopt external connections and continue from where we last left off. there is little that would prevent us from doing the same on generic sigsegvs, i.e. maintain a simple structure that tracks shmif connected descriptors and a copy of input argments. then disable cloexec and set the fds in an arcan_recover envvar and exec ourselves again. sweep and map those fds (force-reset semaphore states), sanity check shmpage content and expose again through the adopt function. possibly also notify the frameservers with a reset event.
there are a few choke points that make debugging noticeably harder: one is the real-time nature of synchronization strategies. the other is, of course, making gdb more lua aware both in core dumps and when stepping. the first point can be counter-acted with support for skewing the running clock and the second must have been solved in some other projects already.
android and particularly its almost unique level of confused and broken userspace (well, linux is getting there...) is not a platform that will get any serious consideration or support. unfortunately, there is a lot of potentially interesting, yet partially broken, hardware in the shape of low-cost arm boards that only kindof-sortof works on android- linux kernel builds (which means we can at least get proper posix shm rather than ashmem, dump pretty much all of the userspace, replace bionic with musl etc.) and nowhere else.
these devices could at least be useful for experiments and odd / fun projects, but to get to that point there need to be some subsystem bring-up, with video being the more daunting one. The libhardware part of the AOSP is surprisingly sane, and particularly their CNativeWindow implementation seems like a way forward, but initial tests yielded little more than crashes on the few tested boards (Radxa, ...).