Date: Wed, 3 Sep 2014 18:59:17 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: libhybris and musl? On Mon, Sep 01, 2014 at 05:08:23PM -0400, Rich Felker wrote: > On Mon, Sep 01, 2014 at 10:55:26AM +0200, Jens Staal wrote: > > Hi > > > > Has anyone tried if libhybris will emulate the bionic libc properly on top of > > musl libc? Alternatively, are there plans for bionic binary/source > > compatibility in musl like the glibc compatibility (or would this contribute > > to bloat?). > > > > I was mostly curious to look into the possiblility of building AOSP (or Mer) > > with musl instead of bionic (or glibc in the case of Mer), but for Android app > > (those built with NDK) compatibility, one would then need libhybris. > > > > right now just thinking aloud - no real plans at the moment :) > > While I haven't look at the details for how it works, I'm fairly > doubtful that using libhybris would be practical. My guess is that After writing this, I had some more ideas based on recent discussions on #musl that were not particularly related to Bionic drivers, but rather the problems with existing FOSS and binary-ware drivers for non-mobile hardware, such as the nvidia drivers, which some users are presently working on using with musl's glibc-ABI-compatibility. 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. 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.