From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3522 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Proposed roadmap to 1.0 Date: Sun, 30 Jun 2013 04:24:10 -0500 Message-ID: <1372584250.2323.1@driftwood> References: <20130630053408.GP29800@brightrain.aerifal.cx> 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 1372648445 9957 80.91.229.3 (1 Jul 2013 03:14:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jul 2013 03:14:05 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-3526-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 05:14:07 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 1UtUZ5-0003bu-7s for gllmg-musl@plane.gmane.org; Mon, 01 Jul 2013 05:14:07 +0200 Original-Received: (qmail 26518 invoked by uid 550); 1 Jul 2013 03:14:06 -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 26507 invoked from network); 1 Jul 2013 03:14:06 -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=pHJ1crZ9kiYhZzOtjt5prhN6wPntdOEbozxpjl8tw6M=; b=DTwXs9DDZ7nZPcLwaKUnh+tPei0dglCGrFrZm6ocGLPuBuXBQFeRVnYkPYVSltguQU Kd9s0+QQ0OR+I9MHF6F+nEzOxRjyu8VS+ZIo1UNncQpZoUfJAWx0u1/98JEvfJMA5NT0 U36gjjWcw2MMXiEbzcTvbknc94pidiPm2kDBo2gY2hWL2yEVBv+MRCucWJMrsFh/HSJv gNJdGGQPnUII3FavXful877xBh6p7frqehvdXp3WPRSgpXGQLwKXvO5gIjs5R17Wf+Oj qbvBIdo2w++ZROnFALMhPplhcqyH+ixww6DZKhwKwIcd1wf8E2xmnQzSNR851vBV4Acp adpw== X-Received: by 10.50.57.16 with SMTP id e16mr13513303igq.14.1372648434280; Sun, 30 Jun 2013 20:13:54 -0700 (PDT) In-Reply-To: <20130630053408.GP29800@brightrain.aerifal.cx> (from dalias@aerifal.cx on Sun Jun 30 00:34:09 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQnWbPYItS/NYgdoWRUBFnyD4Re5Kgrg/gKWyncf1GGSLX+gw0wlde4o0+xp48NWe6avtzWg Xref: news.gmane.org gmane.linux.lib.musl.general:3522 Archived-At: On 06/30/2013 12:34:09 AM, Rich Felker wrote: > On Sat, Jun 29, 2013 at 10:20:45PM -0700, Isaac wrote: > > > 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 =20 > noteworthy, > > > but which has no chance of breaking things that work. Best =20 > candidate > > > would be one or more new ports, labeled experimental. > > > > How about s390 and ia64? ;-) >=20 > s390 looks like a maybe. I'm not sufficiently familiar with it to call > it a no, and Rob seemed interested in supporting it at one time. Yup, qemu has fairly good support for it, klibc supports it, and I got =20 a debian iso to boot under it once (and then be unusable because curses =20 was misconfigured for the console type, but it ran). Between the three =20 I should be able to cobble something up. In general, if klibc, qemu, and my old toolchain support something, I'm =20 interested in getting basic musl support for it. May take a while, =20 though... > ia64 is nothing but gratuitous incompatibility and arch-specific code > where it doesn't belong, all for an arch that was dead before it was > launched. I think it's officially dead now even, or maybe that's just > wishful thinking. I think when SGI finally goes under, it'll be dead. > > All joking aside, I'd say +1. > > And for ports, arm64, mips64 or mips n32, x32, and/or sh seem like > > interesting targets. >=20 > Agreed, all of those look interesting. Super H might be another > candidate; IIRC it was used on some game consoles and automotive > control computers. I just got my sh4 target working again. Had to patch the kernel to stop =20 poking register 0x18 (which makes qemu abort if you read from it, which =20 is just sad)... > > While sparc is not "dead", basically leon is the only sparc cpu =20 > that is > > alive and likely to provide an interested audience. > > And that's sparc32. >=20 > I don't really know much about sparc except that the register windows > system looks ugly. The only sparc target I ever actually got working was sparc32. And the =20 recent openbios upgrade means it hangs as soon as interrupts are =20 enabled under qemu 1.5. But it should be fixable... > > m68k/coldfire are 32-bit only, slow, and largely obsolete with =20 > 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. >=20 > m68k is in some ways an arch I'd like to avoid, but if it's > interesting to people we could do it. qemu doesn't have decent support for it yet. Upstream qemu does =20 coldfire (a nommu m68k subset). There's a fork that tries to emulate =20 the mmu, but the kernel panics as soon as it tries to enable page =20 tables. I've been poking... Laurent Vivier is it? I'd have to look it =20 up and it's 4am here... It's on the todo list, but that requires qemu upgrades. > > Do we currently support 64-bit ppc? >=20 > No, but 32-bit apps can run on 64-bit kernel as far as I know. I was > just looking at the 64-bit ABI earlier today and it's rather > gratuitously ugly, but probably not too hard to support. All the ppc images I've seen do 32 bit userspace under 64 bit kernels. =20 The only architecture that really seems to make a committment to 64 bit =20 userspace is x86_64, and even they're doing x32... (Not saying don't do it, I just haven't found good existing examples to =20 copy.) > > ia64 appears to be limited in use/dying, besides not being the =20 > ideal target. > > (big iron, and you'd pretty much need to interest Oracle and =20 > similar companies > > before you get much use). > > hppa and alpha are most interesting for a computer historian. >=20 > Is hppa the same as pa-risc? If so, it's one I'd definitely like to > omit. It's the only machine with a stack that grows upward, so it's a > good deal of added generality required for just one arch. And of > course like you say it's of interest only to historians. Hewlett Packard PA Risc. The Puffin project, hp-ux... deadish now, I =20 think. > Alpha was kind of interesting, but it's just as dead I think... If I > remember right, the kernel support was broken for years and nobody > realized... Alpha was left behind when Compaq bought the corpse of DEC. Since =20 Compaq didn't make processors it let the Alpha design team go, and AMD =20 snapped them up and had them design the Athlon, and later the Opteron. =20 (That's why it plugs into the Alpha's ev6 bus.) I consider supporting it about on par with supporting m68k, it's a =20 historically important chip and a reasonably nice design, now obsolete =20 but still well supported by hobbyists who remember it fondly. Unfortunately, it has the same qemu problem that m68k does: application =20 emulation is there but system emulation doesn't do the MMU right. (I'm =20 told this has improved since last I looked...) > > 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. >=20 > Not familiar with them, but my guess would be they're interesting. In > embedded, everything has niche uses. On the high-end server side, on > the other hand, anything but x86_64 (for straight power) or ARM (for > cutting the primary cost of a data center: electricity) is madness. In > other words, I think there's a lot more value in supporting diversity > on the embedded side than on the enterprise side. I've been researching this to update =20 http://landley.net/aboriginal/architectures.html but the research is =20 ongoing. (Bits of that page trail off in midsentence...) My problem is =20 when I get started on computer history I blather at huge length. Still, the "when support was added for each architecture" list might be =20 useful as a frame of reference... > Rich Rob=