From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3567 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Proposed roadmap to 1.0 Date: Fri, 05 Jul 2013 10:12:32 -0500 Message-ID: <1373037152.6645.7@driftwood> References: <20130630052045.GB1368@newbook> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1373221237 31914 80.91.229.3 (7 Jul 2013 18:20:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jul 2013 18:20:37 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-3571-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 07 20:20:40 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UvtZc-0001M7-Co for gllmg-musl@plane.gmane.org; Sun, 07 Jul 2013 20:20:36 +0200 Original-Received: (qmail 32208 invoked by uid 550); 7 Jul 2013 18:20:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32197 invoked from network); 7 Jul 2013 18:20:35 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=jQPfS4eLv/PWjgTi1Qs/rKNa5JVTVl1igPqbzABp5Bk=; b=SSW06vTrgS/3EZ7Uvct+DVFFYCsErG6RLA5+iH40TtC2LAf5psCf5yt8vPHLDxxY3L XuXLBNurQeJE0vvhsTN0r9bbSqPRhW7rqokNcZpi54DlisVaWJLnhCtqy+NwcjfpDOwK YQmWMTQWmw1bADJ8SwO9138BzDaXcnwhGVO8fJzyv1XcCaP9XIM/jtSAEm+zimuOzBCm QBdKNdWYmJsj3+b8nx9cGk/5KZJ2AhPR9Hps2jqw1YiqYUcAsXuQRJesp7d+CyYkW52y B37/kQwaOifJ5vGwUUe/wthZgWjXAst7kAVyKBxEbFuakW335HGVWR9IbmPx358IcvNx kOag== X-Received: by 10.236.5.142 with SMTP id 14mr10444607yhl.207.1373221223246; Sun, 07 Jul 2013 11:20:23 -0700 (PDT) In-Reply-To: <20130630052045.GB1368@newbook> (from idunham@lavabit.com on Sun Jun 30 00:20:45 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQnCiJtPe7piPFpN96uFhA/vsuoj/xiQulIAEQZgcxmZbCFx4gro6VckuJWfKgQ1brF2wtxU Xref: news.gmane.org gmane.linux.lib.musl.general:3567 Archived-At: 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. >=20 > +1 >=20 > > 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. >=20 > > 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. >=20 > > 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). >=20 > > 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 =20 > candidate > > would be one or more new ports, labeled experimental. >=20 > How about s390 and ia64? ;-) >=20 > 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 =20 > 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 =20 with qemu 1.5.) There's no uClibc support for 64 bit userspace on most =20 non-x86 targets. (There's Alpha, but qemu doesn't provide any board =20 emulations for that, or the MMU-manipulation instructions. Just =20 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 =20 > systems), > but there is some use of them in the embedded market, so I could =20 > imagine a > port being useful to someone. The m68k target in qemu still isn't quite complete. Laurent Vivier's =20 been fluffing it out at git://gitorious.org/qemu-m68k/qemu-m68k -b q800 =20 (the last m68k mac, had a maximum of 256 megs but that's enough to =20 compile stuff natively). But I haven't poked him about it in a while... > Do we currently support 64-bit ppc? >=20 > ia64 appears to be limited in use/dying, besides not being the ideal =20 > target. > (big iron, and you'd pretty much need to interest Oracle and similar =20 > 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 =20 phone with a qualcomm SOC. It's billed as a multimedia coprocessor, but =20 Linux got ported to it in 2010 and most of the bits are upstream now. =20 There's a linux-hexagon list and everything. The downside is qemu =20 doesn't have support for it, and test systems are hard to come by. (In =20 theory a phone _could_ run vanilla linux. In practice you need an =20 obscureish bootloader and a USB serial driver to talk to the outside =20 world, I've never gotten it set up right. My contract working on it =20 used Comet boards.) Rob=