Re: libhybris and musl?

[Isaac Dunham <ibid.ag@gmail.com>]

On Wed, Sep 03, 2014 at 06:59:17PM -0400, Rich Felker wrote:
> Basically, my view, as expressed many times on #musl, is that all of
> the existing GL drivers, but especially the non-free ones, are full of
> way too much bad code to be safe to load into your program's address
> space. Any process that's loaded them should be treated as potentially
> crashing or aborting at any time, and possibly also has serious
> namespace pollution from random libs getting pulled in.
> 
> The way I'd like to see this solved for our "new platform vision" is
> to move the actual GL implementation out of the address space of the
> application using it, and instead provide a universal libGL for
> applications to link (even statically, if desired) that marshals all
> GL operations over shared-memory-based IPC to a separate process which
> has loaded the actual driver for the target hardware you want to
> render to. As long as the IPC tools used don't depend on a particular
> libc's ABI at all, this should make it trivial to solve the problem
> libhybris aimed to solve at the same time: you simply use Bionic in
> the GL driver process, and your preferred libc with the application
> side libGL.

I saw an implementation of GL based on this design or something very
similar recently.
The point the developer had was to make a GL that could be statically
linked and handle remote rendering.

Ah yes, there it is:
https://github.com/msharov/gleri
"Network protocol, service, and API for using OpenGL remotely."

HTH,
Isaac Dunham