Date: Wed, 28 Aug 2013 01:46:30 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Initial work on post-1.0 roadmap 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.
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.