From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1300 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Draft: musl promo materials Date: Sat, 14 Jul 2012 20:01:50 -0400 Message-ID: <20120715000150.GL544@brightrain.aerifal.cx> References: <20120713181254.GA31206@brightrain.aerifal.cx> <20120713233052.GA1110@brightrain.aerifal.cx> <20120714120515.1b75fddb@newbook> 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: dough.gmane.org 1342310569 8213 80.91.229.3 (15 Jul 2012 00:02:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2012 00:02:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1301-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 15 02:02:49 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SqCIS-0005w7-4z for gllmg-musl@plane.gmane.org; Sun, 15 Jul 2012 02:02:48 +0200 Original-Received: (qmail 11657 invoked by uid 550); 15 Jul 2012 00:02:47 -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 11649 invoked from network); 15 Jul 2012 00:02:47 -0000 Content-Disposition: inline In-Reply-To: <20120714120515.1b75fddb@newbook> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1300 Archived-At: On Sat, Jul 14, 2012 at 12:05:15PM -0700, Isaac Dunham wrote: > On Fri, 13 Jul 2012 19:30:52 -0400 > Rich Felker wrote: > > > Updated version based on some comments.. I think the list is getting > > long enough that it would possibly make sense to reorder/trim it for > > the intended target audience in some usages, and only include the full > > thing on the website. > > > > Rich > > > > > > ---------------------------------------------------------------------- > > > > Consistent quality and implementation behavior from tiny embedded > > systems to full servers. > > > > Minimal machine-specific code, meaning less chance of breakage on > > minority architectures and better success with "write once run > > everywhere" development. > > One criticism I've heard (not saying I agree!) is that you lose > performance with musl thanks to most functions being in C... I haven't found that to be the case. When it is, asm can be added if needed. If you're aware of some operations that are significantly slower than glibc and believe lack of asm is the problem, please report them. > > Realtime-quality robustness. No unnecessary dynamic allocation. No > > unrecoverable late failures. No lazy binding or lazy allocation. > > > This reminded me about _XOPEN_REALTIME: > "This Option Group consists of the set of the following options from > within POSIX.1-2008 (see Options ): > [...] > I'm curious how far from complete _XOPEN_REALTIME support musl is. When I refer to realtime-quality, it's a matter of the entire library having suitable characteristics for realtime use - things like not crashing from resouce exhaustion, not having gratuitious resource contention issues, etc. The _XOPEN_REALTIME option is full of extra functionality that's useful for programming idioms that are commonly used/taught for realtime programming, which is a separate issue. Amusingly, some libcs go out of their way to support the latter and completely fail to support the former, making the latter utterly useless. Rich