Re: Proposed roadmap to 1.0

[Rob Landley <rob@landley.net>]

On 06/30/2013 12:20:45 AM, Isaac wrote:
> On Sat, Jun 29, 2013 at 07:50:41PM -0400, Rich Felker wrote:
> > Hi all,
> >
> > Here is a VERY tentative, proposed roadmap towards a 1.0 release of
> > musl. Comments welcome!
> >
> > 0.9.11
> > Projected release: ASAP
> > No further goals at the moment except fixing additional bugs found.
> 
> +1
> 
> > 0.9.12
> > Projected release: Mid to late July
> > Key targets:
> > - Overhaul of time handling, including zoneinfo support.
> > - Overhaul resolver to better provide legacy APIs without code dup.
> > - Hybrid automatic/manual audit for cruft and code smells.
> > - Resolve symlink direction issue for dynamic linker.
> > - Affinity/cpuset interfaces.
> 
> > 0.9.13
> > Projected release: Early August
> > Key targets:
> > - Full C++ ABI compatibility with glibc/LSB.
> > - Support for all remaining iconv charsets of interest (KR/TW/HK).
> > - Possible overhaul of iconv for performance and clarity/simplicity.
> > - Possibly add stateful iconv support.
> > - Establish formal procedure for regression testing.
> 
> > 0.9.14
> > Projected release: End of summer
> > Key targets:
> > - Complete documentation draft.
> > - Performance testing on under-tested archs, fixing bottlenecks hit.
> > - Review for gratuitous application breakage (anything that could be
> >   fixed with trivial changes that don't hurt musl's quality).
> 
> > 1.0.0
> > Projected release: Early fall
> > Key targets:
> > - Polished documentation.
> > - Organized and coordinated publicity plan.
> > - At least one new exciting addition to make the release noteworthy,
> >   but which has no chance of breaking things that work. Best  
> candidate
> >   would be one or more new ports, labeled experimental.
> 
> How about s390 and ia64? ;-)
> 
> All joking aside, I'd say +1.
> And for ports, arm64, mips64 or mips n32, x32, and/or sh seem like
> interesting targets.
> While sparc is not "dead", basically leon is the only sparc cpu that  
> is
> alive and likely to provide an interested audience.
> And that's sparc32.

I only ever did sparc32 in aboriginal. (And _just_ got it fixed to work  
with qemu 1.5.) There's no uClibc support for 64 bit userspace on most  
non-x86 targets. (There's Alpha, but qemu doesn't provide any board  
emulations for that, or the MMU-manipulation instructions. Just  
application emulation.)

> m68k/coldfire are 32-bit only, slow, and largely obsolete with little
> prospect of new development (Freescale is working on ppc and arm  
> systems),
> but there is some use of them in the embedded market, so I could  
> imagine a
> port being useful to someone.

The m68k target in qemu still isn't quite complete. Laurent Vivier's  
been fluffing it out at git://gitorious.org/qemu-m68k/qemu-m68k -b q800  
(the last m68k mac, had a maximum of 256 megs but that's enough to  
compile stuff natively). But I haven't poked him about it in a while...

> Do we currently support 64-bit ppc?
> 
> ia64 appears to be limited in use/dying, besides not being the ideal  
> target.
> (big iron, and you'd pretty much need to interest Oracle and similar  
> companies
> before you get much use).

Let ia64 die.

> hppa and alpha are most interesting for a computer historian.

Which would be me. :)

> m32r is live, but I'm not aware of much interest.
> tilera and epiphany (the Parallela coprocessor) sound interesting,
> but are likely to be limited in availability.

Hexagon's in every snapdragon chipset which is basically any Android  
phone with a qualcomm SOC. It's billed as a multimedia coprocessor, but  
Linux got ported to it in 2010 and most of the bits are upstream now.  
There's a linux-hexagon list and everything. The downside is qemu  
doesn't have support for it, and test systems are hard to come by. (In  
theory a phone _could_ run vanilla linux. In practice you need an  
obscureish bootloader and a USB serial driver to talk to the outside  
world, I've never gotten it set up right. My contract working on it  
used Comet boards.)

Rob