[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 26 Apr 2013 11:53:05 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
On Fri, Apr 26, 2013 at 07:57:36PM +0700, Muhammad Sumyandityo Noor wrote:
> You meant replacement for Mesa? Because TinyGL is software renderer.
> It's unlikely people will utilize software renderer. As for embedded
> system, each SoCs provides their own userland to utilize its
> hardware accelerator.
I don't really understand the GL architecture presently in use well
enough to know the right solutions, but if I'm not mistaken, it
involves loading dynamic modules, possibly even binaryware
hardware-vendor-provided ones, into the address space of your
application. This seems like a recipe for disaster.
Software-rendered GL is definitely not the solution, but I wonder if
it would be reasonable to create a library that provides the OpenGL
API with NO namespace pollution or introduction of dangerous code into
the application's address space, by cooperating with a separate
process via shared memory. On modern Linux, this separate process
could use Linux namespaces to completely throw away all privileges
except to the graphics device. Then the nasty legacy OpenGL code could
run in a sandbox.
Rich
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.
