Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Sep 2014 08:17:09 -0700
From: Isaac Dunham <>
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:
"Network protocol, service, and API for using OpenGL remotely."

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.