Initial work on post-1.0 roadmap

[Rich Felker <dalias@aerifal.cx>]

This message is purely some notes for tracking and possible discussion
of things to do after musl 1.0 is released. I'm leaning towards (but
undecided) maintaining separate 1.0.x and 1.1.x branches after the 1.0
release, the 1.0.x being just bug-fixes and backports of non-invasive
changes, and real development taking place in the 1.1.x series. The
below items should probably then be arranged into a 1.1.x-series
roadmap based on how much seems reasonable to get done per release
(roughly, per month), and which features are in the highest demand.

Rich



----

Full C11 support -- mainly threads and uchar.h remain. Annex K is
still a possibility too but I'd probably rather wait and see if other
implementations and applications adopt it rather than have musl be
part of the driving force for its adoption.

Removing lazy-init of thread pointer. This will add a one-syscall
overhead at startup even in programs which don't need it, but will
allow large optimizations in many places, including optimizations
which reduce code size and bloat. However this item is contingent on
making sure it does not preclude support for ancient kernels where the
thread pointer setup syscalls are missing.

Overhauling iconv -- stateful conversions, user-defined charmaps,
reverse mapping for CJK, and performance improvements. Some of these
items may be done pre-1.0 if I get time.

Locale support, including both fixing the C locale LC_CTYPE issues and
adding useful, non-harmful categories like LC_TIME, LC_MESSAGES,
LC_COLLATE, and LC_MONETARY.

Support for non-flat-file passwd database backend.

Overhauling POSIX AIO. Details are linked on the wiki (Open Issues).

Switching to private futexes.

Improving resolver and IPv6 support further -- things like scope
identifiers for link-local addresses, automatic detection of
availability of IPv6, IDNs, search domains, resolv.conf options and
environment overrides, etc. Some of these improvements may take place
before 1.0, if I have time.

Improving the complex math library.

Simplifying the process of porting. Possibly adding skeleton files for
new ports, or tools to auto-generate arch-specific files from a
minimal description of the arch-specific properties. This might begin
before 1.0 if there are people interested in working on ports who
could benefit from it.