From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3222 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Fri, 26 Apr 2013 11:53:05 -0400 Message-ID: <20130426155305.GR20323@brightrain.aerifal.cx> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130425211914.2d98535d.idunham@lavabit.com> <517A79C0.50502@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1366991596 13964 80.91.229.3 (26 Apr 2013 15:53:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Apr 2013 15:53:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3226-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 26 17:53:21 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UVkxa-00009J-Mx for gllmg-musl@plane.gmane.org; Fri, 26 Apr 2013 17:53:18 +0200 Original-Received: (qmail 32610 invoked by uid 550); 26 Apr 2013 15:53:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32602 invoked from network); 26 Apr 2013 15:53:17 -0000 Content-Disposition: inline In-Reply-To: <517A79C0.50502@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3222 Archived-At: 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