From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7194 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: ideas for build system changes, bits refactoring Date: Sun, 15 Mar 2015 20:25:43 -0400 Message-ID: <20150316002543.GV23507@brightrain.aerifal.cx> References: <20150312035954.GA31639@brightrain.aerifal.cx> <20150315234755.GA27261@duality.lan> 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 1426465560 25193 80.91.229.3 (16 Mar 2015 00:26:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Mar 2015 00:26:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7207-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 16 01:25:59 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 1YXIr0-0001co-1r for gllmg-musl@m.gmane.org; Mon, 16 Mar 2015 01:25:58 +0100 Original-Received: (qmail 15716 invoked by uid 550); 16 Mar 2015 00:25:56 -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 15698 invoked from network); 16 Mar 2015 00:25:55 -0000 Content-Disposition: inline In-Reply-To: <20150315234755.GA27261@duality.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7194 Archived-At: On Sun, Mar 15, 2015 at 06:47:56PM -0500, Bobby Bingham wrote: > > 2. Factor arch bits (types, struct layouts, constant values, etc.) as > > a sequence of overlays: a generic base, several common families like > > 32-bit, 64-bit, 64-bit+ILP32, ld-64, ld-80, ld-128, and finally > > arch-specific bits. The latter should be nearly empty for most archs. > > Do you mean that a final bits header would come from one of these > overlays that hadn't been overridden by another overlay, or would be a > composite built from pieces provided by the different overlays? > > For example, powerpc/bits/errno.h is nearly identical to the file used > on most other architectures, just with a different value of EDEADLOCK. > Would the powerpc arch-specific errno.h need to redefine all of the > values, or would it be able to inherit most of the values from the > generic base and just override EDEADLOCK? I don't have a plan in mind for this yet. Obviously there are simplifying/deduplication benefits to being able to make small replacements like this, but in order to make sense there needs to be a net savings still even after we implement whatever part of the build script would be responsible for merging them. I'm not sure how that would work. This could of course be done in multiple phases, where the first phase is just cp'ing the 'best match' overlay and we later add fancier merging. > 5. This may be orthogonal to the rest of these ideas, but what about > providing thin wrappers for the syscalls used by musl itself, similar to > the __sys_open* macros already provided by internal/syscall.h? I think > it would help for bare metal targets to be able to implement one > individual function per syscall, rather than needing to implement a > whole syscall dispatcher. Yes. I'd still like to explore what changes users wanting to do bare-metal stuff with musl would like to see. I agree it's sort of orthogonal to the above. Rich