From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6864 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0KDRi9GB0Yw=?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl and android Date: Sun, 18 Jan 2015 15:01:19 +0700 Message-ID: <20150118150119.1a80a4ba@sibserver.ru> References: <20150115161322.4ee903b7@sibserver.ru> <20150118133237.40beda09@sibserver.ru> <20150118064440.GA4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1421567731 7930 80.91.229.3 (18 Jan 2015 07:55:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Jan 2015 07:55:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6877-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 18 08:55:31 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YCkhk-0008SK-OI for gllmg-musl@m.gmane.org; Sun, 18 Jan 2015 08:55:28 +0100 Original-Received: (qmail 7260 invoked by uid 550); 18 Jan 2015 07:55:26 -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 7252 invoked from network); 18 Jan 2015 07:55:26 -0000 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS autolearn=ham autolearn_force=no version=3.4.0 In-Reply-To: <20150118064440.GA4574@brightrain.aerifal.cx> X-Mailer: claws-mail Xref: news.gmane.org gmane.linux.lib.musl.general:6864 Archived-At: =D0=92 Sun, 18 Jan 2015 01:44:40 -0500 Rich Felker =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sun, Jan 18, 2015 at 01:32:37PM +0700, =D0=A0=D1=8B=D1=81=D1=8C wrote: > > =D0=92 Thu, 15 Jan 2015 16:13:22 +0700 > > =D0=A0=D1=8B=D1=81=D1=8C =D0=BF=D0=B8=D1=88=D0=B5= =D1=82: > >=20 > > > Hello all! > > >=20 > > > Are there any efforts or even a project which aims to port musl to > > > android platform? > > >=20 > > > For a year I slowly had built and running a couple of C tty only > > > programs such as iptables, tcpdump and of course busybox and many > > > others including my own with musl libc linked statically. They > > > work perfectly (no much differences between an ARM phone and, for > > > example, raspberry pi SoC) but a few items I missed: > > >=20 > > > + Proper DNS resolving is not available > > > + Translation of android special user names is not done > > >=20 > > > As an advanced Linux user I know that android is not friendly > > > enough to plain C stuff and it's libc is even not finished now so > > > I aimed to port at least listed things to musl. > > >=20 > > > Because I am not going beyond listed items, a patch can be > > > developed just to support these inside musl-linked binaries. > > >=20 > > > I am first here or there is already someone who done this before? > >=20 > > I made a patch to implement all three things for musl on android. > >=20 > > I do not post it here as attachment to this mail because it normally > > should not be integrated with musl. The patch itself is here: > > http://lynxlynx.tk/prg/patches/musl-1.1.4_android.patch, notes about > > it: http://lynxlynx.tk/eng/musl_android/. > >=20 > > Patch is invasive enough I think and not optimized and I agree with > > Rich that it must go as a special treat. I tried however move away > > all translating code to src/android and headers to include/android. > >=20 > > Patch is still in it's alpha stage, and probably will be changed > > often. > >=20 > > Modifications made for musl 1.1.4. > >=20 > > If anyone interested to audit it - welcome! >=20 > Thanks. If nothing else, this is very informative as to how Android > does things. I noticed a couple things that could be a lot less > invasive, I think, particularly the builtin users/groups. Couldn't you > just fmemopen() a constant string inside libc in place of /etc/passwd > or /etc/group and use the existing code to parse it? This sounds more interesting idea, I forgot that get*ent() open fd and there is fmemopen() function. But app_/ux_ax names still need a dedicated translation function, probably the same code which will form a passwd-like string and feed it into get*ent(). >=20 > One thing I noticed -- you seem to have some memory leaks in the code > that produces the passwd/group output -- it's malloc'ing space for > names each time and I don't see anywhere it gets freed. Maybe I'm > missing something though; I just read it briefly. Yes the patch is alpha and the reason why there is so much code is that I did not know how get*ent() were implemented in musl from beginning, and learned them only when translation code was ready. This patch is just to show how a translation layer can be implemented on musl to (completely) port it to android, and I am probably going to completely rewrite uid/name translation code based on your suggestion in next days (or at least try to). Memory leaks are expected now :( >=20 > Another general question I have is why can't the /system issue be > fixed? Is there any good reason Android doesn't have symlinks like > /bin->/system/bin, /etc->/system/etc, /lib->/system/lib, > /tmp->/data/tmp, etc.? The gratuitous incompatibility is really > disgusting. First, android has /etc -> /system/etc in place, but, unfortunately, no more :( I made /etc -> /system/etc change just because I distrust symlinks when doing security things. It is usually stable across devices, but it's just symlink. It even does not have usual Unix /tmp directory or it's surrogate somewhere in filesystem. /data/tmp is my adoption, though it's non-standard on android. Second, android has a very different bootup process, and all those links in / are created during bootup (on a tmpfs?). Sadly only /etc is defined by android developers to be symlink to /system/etc. Third, there are probably many differences between many android device vendors, android OS types (different android versions including ancient ones, different android forks that exist today, vendor customisations of fs layout and in future many others). In fact, android is _very_ fragmented OS. All this is based on my experience with some android devices I working (and worked) with. >=20 > Rich Your additional input on this will be welcome, thanks!