From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6863 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl and android Date: Sun, 18 Jan 2015 01:44:40 -0500 Message-ID: <20150118064440.GA4574@brightrain.aerifal.cx> References: <20150115161322.4ee903b7@sibserver.ru> <20150118133237.40beda09@sibserver.ru> 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: 8bit X-Trace: ger.gmane.org 1421563496 16476 80.91.229.3 (18 Jan 2015 06:44:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Jan 2015 06:44:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6876-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 18 07:44:55 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 1YCjbT-0008Pf-Df for gllmg-musl@m.gmane.org; Sun, 18 Jan 2015 07:44:55 +0100 Original-Received: (qmail 5159 invoked by uid 550); 18 Jan 2015 06:44:53 -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 5142 invoked from network); 18 Jan 2015 06:44:53 -0000 Content-Disposition: inline In-Reply-To: <20150118133237.40beda09@sibserver.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6863 Archived-At: On Sun, Jan 18, 2015 at 01:32:37PM +0700, Рысь wrote: > В Thu, 15 Jan 2015 16:13:22 +0700 > Рысь пишет: > > > Hello all! > > > > Are there any efforts or even a project which aims to port musl to > > android platform? > > > > 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: > > > > + Proper DNS resolving is not available > > + Translation of android special user names is not done > > > > 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. > > > > Because I am not going beyond listed items, a patch can be developed > > just to support these inside musl-linked binaries. > > > > I am first here or there is already someone who done this before? > > I made a patch to implement all three things for musl on android. > > 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/. > > 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. > > Patch is still in it's alpha stage, and probably will be changed often. > > Modifications made for musl 1.1.4. > > If anyone interested to audit it - welcome! 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? 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. 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. Rich