From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2361 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Design idea for subarchs/abivariants Date: Wed, 28 Nov 2012 20:21:08 -0500 Message-ID: <20121129012107.GV20323@brightrain.aerifal.cx> References: <20121128192618.GA7491@brightrain.aerifal.cx> <20121128223801.GL10895@port70.net> <20121129001042.GU20323@brightrain.aerifal.cx> <20121129002251.GA13394@intma.in> 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 1354152081 20261 80.91.229.3 (29 Nov 2012 01:21:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Nov 2012 01:21:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2362-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 29 02:21:31 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 1Tdsol-00058r-Ie for gllmg-musl@plane.gmane.org; Thu, 29 Nov 2012 02:21:31 +0100 Original-Received: (qmail 14171 invoked by uid 550); 29 Nov 2012 01:21:20 -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 14159 invoked from network); 29 Nov 2012 01:21:19 -0000 Content-Disposition: inline In-Reply-To: <20121129002251.GA13394@intma.in> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2361 Archived-At: On Wed, Nov 28, 2012 at 07:22:51PM -0500, Kurt H Maier wrote: > On Wed, Nov 28, 2012 at 07:10:42PM -0500, Rich Felker wrote: > > Yes, I thought about this too and even started writing the email that > > way before deleting what I wrote and rewriting it. I was trying to > > avoid more nested and conditional inclusion, but I don't think it > > would actually be too costly to do it the way you proposed. > > I'm asking this to be educated, rather than to make a point: why is a > system like this preferable to the way plan9 libc is written, which as > far as I can tell uses no ifdef at all? Right now, musl uses separate bits headers for each arch rather than trying to share them between archs with #ifdef hackery. I agree this is much cleaner. But it's been polluted slightly by the fact that a few archs have both little and big endian variants, and the desire to avoid duplicating the whole arch for just that one variation. Now, the need to support more variants for some of these (like mips softfloat) is making the situation even worse. Using generated headers like I originally proposed would of course allow us to avoid #ifdef hackery, and even allow us to eliminate what already exists in endian.h. Rich