[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150315234755.GA27261@duality.lan>
Date: Sun, 15 Mar 2015 18:47:56 -0500
From: Bobby Bingham <koorogi@...rogi.info>
To: musl@...ts.openwall.com
Subject: Re: ideas for build system changes, bits refactoring
On Wed, Mar 11, 2015 at 11:59:54PM -0400, Rich Felker wrote:
> I'd like to start a list of ideas and discussion for changes we could
> make to the build system and arch bits. This has been on the agenda a
> long time but it's going to be more important as we get more ports,
> both as a way of managing complexity and as a way of fighting source
> tree bloat. Here are some ideas I have so far:
>
> 1. Generate all installable include files, even if just by copying, as
> part of the build. If nothing else, this will ensure that "make clean"
> followed by "make install" overwrites any (non-future-dated)
> preexisting files at the install destination; right now, that might
> fail to happen if changes were made at the install destination and the
> source timestamp is older. I think this will also make it easier to
> add out-of-tree build since there won't need to be separate logic for
> generated headers in-tree vs out-of-tree. It will also give us the
> option (not sure if we should take it) to merge bits into the main
> headers rather than having a bits dir under include.
>
> 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?
>
> 3. Moving arch-specific build logic out of the configure script and
> into a makefile fragment in the arch dir. This should support the
> long-term goal of reducing/eliminating the work configure does and
> moving it to declarative rules in make. It also isolates
> port-specific logic with the port rather than hard-coding it in a
> shared script.
>
> 4. Eliminate the duplication of SYS_* and __NR_* in syscall.h bits by
> auto-generating one from the other as part of the build process.
>
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.
>
> Rich
--
Bobby Bingham
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
