Initial work on post-1.0 roadmap

Initial work on post-1.0 roadmap

[Rich Felker]

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.

Re: Initial work on post-1.0 roadmap

[Rich Felker]

On Wed, Aug 28, 2013 at 01:46:30AM -0400, Rich Felker wrote:
> 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.

One more item (well, a big multi-part item):

Security features -- RELRO processing in the dynamic linker, a
replacement for _FORTIFY_SOURCE (as a layer on top of libc's headers
rather than part of libc's headers), making it possible to build libc
itself with stack-protector, possibly nonstandard interfaces needed
for using kernel security features well, adapting malloc's footer
bookkeeping to make it difficult to preserve footer when performing
buffer overflows, ...

Rich

Re: Initial work on post-1.0 roadmap

[Rob Landley]

On 08/30/2013 12:03:57 PM, Rich Felker wrote:
> On Wed, Aug 28, 2013 at 01:46:30AM -0400, Rich Felker wrote:
> > 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.
> 
> One more item (well, a big multi-part item):
> 
> Security features -- RELRO processing in the dynamic linker, a
> replacement for _FORTIFY_SOURCE (as a layer on top of libc's headers
> rather than part of libc's headers), making it possible to build libc
> itself with stack-protector, possibly nonstandard interfaces needed
> for using kernel security features well, adapting malloc's footer
> bookkeeping to make it difficult to preserve footer when performing
> buffer overflows, ...

This isn't on the wiki...?

Rob

Re: Initial work on post-1.0 roadmap

[Rich Felker]

On Thu, Sep 05, 2013 at 06:14:13AM -0500, Rob Landley wrote:
> On 08/30/2013 12:03:57 PM, Rich Felker wrote:
> >On Wed, Aug 28, 2013 at 01:46:30AM -0400, Rich Felker wrote:
> >> 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.
> >
> >One more item (well, a big multi-part item):
> >
> >Security features -- RELRO processing in the dynamic linker, a
> >replacement for _FORTIFY_SOURCE (as a layer on top of libc's headers
> >rather than part of libc's headers), making it possible to build libc
> >itself with stack-protector, possibly nonstandard interfaces needed
> >for using kernel security features well, adapting malloc's footer
> >bookkeeping to make it difficult to preserve footer when performing
> >buffer overflows, ...
> 
> This isn't on the wiki...?

Indeed, the items that aren't yet there should be added to Open
Issues, and a new Roadmap section for post-1.0 work should be added.
I'll try to get to that soon.

Rich