From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7910 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: Build option to disable locale [was: Byte-based C locale, draft 1] Date: Mon, 8 Jun 2015 20:20:26 -0700 Message-ID: <20150609032025.GA1605@localhost> References: <20150606214007.GA17398@brightrain.aerifal.cx> <55737684.7020803@gmx.de> <20150606231057.GZ17573@brightrain.aerifal.cx> <55738979.4030809@gmx.de> <20150607002459.GA17573@brightrain.aerifal.cx> <5574DAE7.8040101@gmx.de> <20150608003315.GD17573@brightrain.aerifal.cx> <55750212.5090304@gmx.de> 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 1433820029 12344 80.91.229.3 (9 Jun 2015 03:20:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Jun 2015 03:20:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7923-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 09 05:20:29 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 1Z2A5U-0003DJ-9r for gllmg-musl@m.gmane.org; Tue, 09 Jun 2015 05:20:28 +0200 Original-Received: (qmail 5135 invoked by uid 550); 9 Jun 2015 03:20:25 -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 4087 invoked from network); 9 Jun 2015 03:20:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VF7omUR2mBRP/7b7gX0YFM5tKJ72al4X9/WHynxqwfU=; b=pXtbs5CvT+PDA8L7RKqWaKFwLycKWI2OxFJGJ0v+Wbm9+l1XNvnFolXmc89PuIcpZL bb35w742SevIrJCmL3CiD0t7LeDbDE7EzymRqV2t87Apy4l1u47iGEotOyiyK1O3WWyk dkG7BbxH21ow38BGw3cFBcH49/v6ggAELRfChGbCXvCB/o42IT8IQRExXGvuwENPx61t M7RhImt/co83oE69PECnE7zO3UTnBn9OTXY5VHHkTzAiz9MHGCMS8XkgBdnxgn0Na3Oj QP+gdQ30Nx/+MLDfR04B9ozwwXGxkmpDhLA3++wKeJB4yc/tQA6QtbFnrk+AOzy4/BUT 7P9Q== X-Received: by 10.68.135.136 with SMTP id ps8mr13361816pbb.78.1433820013267; Mon, 08 Jun 2015 20:20:13 -0700 (PDT) Content-Disposition: inline In-Reply-To: <55750212.5090304@gmx.de> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7910 Archived-At: On Mon, Jun 08, 2015 at 04:46:42AM +0200, Harald Becker wrote: > On 08.06.2015 02:33, Rich Felker wrote: > >So aside from iconv, the above seem to total around 19k, and at least > >6k of that is mandatory if you want to be able to claim to support > >UTF-8. So the topic at hand seems to be whether you can save <13k of > >libc.so size by hacking out character handling/locale related features > >that are non-essential to basic UTF-8 support... > > I like to get a stripped down version, which eliminate all the unnecessary > char set handling code used in dedicated systems, but stripping that on > every release is too much work to do. > > The benefit may be for: > > - embedded systems > - small initramfs based systems > - container systems > - minimal chroot environments Somehow it sounds like you may not have gotten wat Rich was asking. IIRC, the goals of musl include full native support for UTF-8; keeping the time complexity to a minimum; and clean, correct code. Dropping out 'legacy' charsets doesn't really sacrifice those goals. But the other changes are have a much bigger impact on them. So you're probably going to have to convince Rich that there *is* a major benefit ('is' != 'could be'). For container systems or minimal chroot environments, you're dealing with something that doesn't have a hard size limit, and if a chroot or container runs ~6 MB ordinarily, you might be able to run 0.3% more on the same hardware. That's probably not enough of a case. For initramfs-based systems, you've got a similar situation but no chance to multiply the effect, unless you're using a VM or hypervisor. Now, since embedded systems have hard limits on size, you might be able to make a case there. But you will need to come up with somthing more specific, such as "I have a system where I could upgrade the kernel to 2.6.xx *if* musl were ~20k smaller than building with a minimal iconv" or "If we did this, there would be enough space to switch XYZ router firmware from telnetd to dropbear". HTH, Isaac Dunham