Date: Thu, 4 Sep 2014 08:17:09 -0700 From: Isaac Dunham <ibid.ag@...il.com> To: musl@...ts.openwall.com Subject: Re: libhybris and musl? 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
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.