[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140903225917.GO12888@brightrain.aerifal.cx>
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.
