From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3510 Path: news.gmane.org!not-for-mail From: Justin Cormack Newsgroups: gmane.linux.lib.musl.general Subject: Re: Proposed roadmap to 1.0 Date: Sun, 30 Jun 2013 08:21:25 +0100 Message-ID: References: <20130629235041.GA5046@brightrain.aerifal.cx> <20130630052045.GB1368@newbook> <20130630053408.GP29800@brightrain.aerifal.cx> <20130630064248.GC1368@newbook> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33946dafe31f04e059f555 X-Trace: ger.gmane.org 1372576901 4126 80.91.229.3 (30 Jun 2013 07:21:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Jun 2013 07:21:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3514-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 30 09:21:44 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 1UtBx8-0001P3-Bh for gllmg-musl@plane.gmane.org; Sun, 30 Jun 2013 09:21:42 +0200 Original-Received: (qmail 23698 invoked by uid 550); 30 Jun 2013 07:21:38 -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 23687 invoked from network); 30 Jun 2013 07:21:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=specialbusservice.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pnOrKYoQJp952yIvsR9FfwGGLzEdZg/2rlMxkqFqg94=; b=ASNMY9vefj8p8fmzvbBF1XnvYHDoeLX4FViCUrXcCjBf6v8Fv6ZT9n5G3vH9IbnT87 sHsgP91iAUdRz1/arMASI1PBupt+J5F0CzNWUpZw1SdEX61C7An1exgZIcvFu1/MvFg0 gdToijP3gMgGW/F8NAVdng6pSxQRylcgNkKP8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=pnOrKYoQJp952yIvsR9FfwGGLzEdZg/2rlMxkqFqg94=; b=mIvjy2fG5Ebzf+7qnTBHVd4OFBhLQflVcYxYGDfcsq45xGWl4NDIWYR5LW2L3qMj/q CApNpCg05Wi9gtVBD99PssYYDQE0rg8B5ZTqIflDBuKur1WjSCQ7UNVb826wS4uQ/Rx8 QRLJJFPLCrhyTUDyC9l0+w9vqyXHUrYzH6YMLsJnSwlBIJko6c9n4fQOLscu1kSg5OwL HgFvFvoG37/c9HSK8t4kjPqVTut7+la5Ctg6b8U6+sRB+nHNPs/lIyMbsmITRQ0MVbhW tSm7Hoe89hwiY+Zw9HOsH8b0L/LH77bTTohEZF1KCGcOl5L8/nQhmQkF1AlJHky2YX76 QLoA== X-Received: by 10.68.230.40 with SMTP id sv8mr18521109pbc.30.1372576885492; Sun, 30 Jun 2013 00:21:25 -0700 (PDT) In-Reply-To: <20130630064248.GC1368@newbook> X-Gm-Message-State: ALoCoQn2dc9pGrD4vUBpj8LbbiP7qpCbF1Cm64ddvg+ZJf2M7ttSLKbR+KUKkmFnGkN3tPW7Y+gv Xref: news.gmane.org gmane.linux.lib.musl.general:3510 Archived-At: --047d7b33946dafe31f04e059f555 Content-Type: text/plain; charset=UTF-8 On 30 Jun 2013 07:43, "Isaac" wrote: > > On Sun, Jun 30, 2013 at 01:34:09AM -0400, 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 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? ;-) > > > > 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. > > > > 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. > > > > All joking aside, I'd say +1. > > I mentioned those as the two worst candidates I could think of (hence the > "all joking aside"). s390 is a 31-bit (yes, really) architecture; to be > precise, it's the discontinued IBM System/390 architecture, which has been > replaced with a 64-bit cpu. > All along it has been a mainframe platform. > > > > And for ports, arm64, mips64 or mips n32, x32, and/or sh seem like > > > interesting targets. > > > > Agreed, all of those look interesting. Super H might be another > > candidate; IIRC it was used on some game consoles and automotive > > control computers. > > Super H == sh for short. I'm using Debian's port names. > > > > 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 don't really know much about sparc except that the register windows > > system looks ugly. > > > > > 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. > > > > m68k is in some ways an arch I'd like to avoid, but if it's > > interesting to people we could do it. > > I'm mentioning it as potentially making sense in terms of the usage. > > > > Do we currently support 64-bit ppc? > > > > 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. > > Apparently, it's also slower on some CPUs: > http://www.yellowdog-board.com/viewtopic.php?p=23037#p23037 I think that may not be true with newer silicon. IBM apparently no longer ship 32 bit userspace compatibility code. You can get access to new hardware at no cost through their partner program. Plus I still have one. MIPS64 would be nice as the Chinese are making them (Loongson) for general use. Justin > > 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 > Yes. > > > > 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. > > > > Not familiar with them, but my guess would be they're interesting. In > > Tilera Tile: > http://www.tilera.com/products/processors > In brief, it's a 64-bit processor that comes with up to 100 cores per cpu > (last I checked), topping out around 1.6 GHz. Linux is the only OS. > > Epiphany: > http://www.adapteva.com/introduction/ > Used in this project: > http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone/ > In short, a multicore 32-bit risc cpu currently only used as a coprocessor. > Not really a candidate for a port, but if it ever does get a full Linux, > it might be interesting. > > > 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. > > Power has a bit of the enterprise, too; it's got lower power usage (vs > x86, no comparisons with ARM I'm aware of), and currently holds the > highest clock speed of any stock cpu. > But I'd somehow expect embedded to be more open to a new libc than > enterprise; for the latter, we'd need either a big vendor using musl > or a distro (Debian/RHEL/SLES) using it...most likely in place of > klibc / newlib / dietlibc, for static rescue tools or for the initrd. > > Which reminds me... > I've been in contact with someone working on a musl package for Debian: > https://github.com/wermut/musl/ > He's currently looking for a sponsor/mentor, and has packaging that is > co-installable with libc6. > > Isaac Dunham > --047d7b33946dafe31f04e059f555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 30 Jun 2013 07:43, "Isaac" <idunham@lavabit.com> wrote:
>
> On Sun, Jun 30, 2013 at 01:34:09AM -0400, 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 releas= e noteworthy,
> > > > =C2=A0 but which has no chance of breaking things that = work. Best candidate
> > > > =C2=A0 would be one or more new ports, labeled experime= ntal.
> > >
> > > How about s390 and ia64? ;-)
> >
> > s390 looks like a maybe. I'm not sufficiently familiar with i= t to call
> > it a no, and Rob seemed interested in supporting it at one time.<= br> > >
> > 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 tha= t's just
> > wishful thinking.
>
> > > All joking aside, I'd say +1.
>
> I mentioned those as the two worst candidates I could think of (hence = the
> "all joking aside"). s390 is a 31-bit (yes, really) architec= ture; to be
> precise, it's the discontinued IBM System/390 architecture, which = has been
> replaced with a 64-bit cpu.
> All along it has been a mainframe platform.
>
> > > And for ports, arm64, mips64 or mips n32, x32, and/or sh see= m like
> > > interesting targets.
> >
> > Agreed, all of those look interesting. Super H might be another > > candidate; IIRC it was used on some game consoles and automotive<= br> > > control computers.
>
> Super H =3D=3D sh for short. I'm using Debian's port names. >
> > > While sparc is not "dead", basically leon is the o= nly sparc cpu that is
> > > alive and likely to provide an interested audience.
> > > And that's sparc32.
> >
> > I don't really know much about sparc except that the register= windows
> > system looks ugly.
> >
> > > m68k/coldfire are 32-bit only, slow, and largely obsolete wi= th 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 c= ould imagine a
> > > port being useful to someone.
> >
> > m68k is in some ways an arch I'd like to avoid, but if it'= ;s
> > interesting to people we could do it.
>
> I'm mentioning it as potentially making sense in terms of the usag= e.
>
> > > Do we currently support 64-bit ppc?
> >
> > 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<= br> > > gratuitously ugly, but probably not too hard to support.
>
> Apparently, it's also slower on some CPUs:
> http://www.yellowdog-board.com/viewtopic.php?p=3D23037#p23037

I think that may not be true with newer silicon. IBM apparen= tly no longer ship 32 bit userspace compatibility code. You can get access = to new hardware at no cost through their partner program. Plus I still have= one.

MIPS64 would be nice as the Chinese are making them (Loongso= n) for general use.

Justin

> > 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, s= o it's a
> Yes.
>
> > > m32r is live, but I'm not aware of much interest.
> > > tilera and epiphany (the Parallela coprocessor) sound intere= sting,
> > > but are likely to be limited in availability.
> >
> > Not familiar with them, but my guess would be they're interes= ting. In
>
> Tilera Tile:
> http://www.tiler= a.com/products/processors
> In brief, it's a 64-bit processor that comes with up to 100 cores = per cpu
> (last I checked), topping out around 1.6 GHz. Linux is the only OS. >
> Epiphany:
> http://www.adapteva.= com/introduction/
> Used in this project:
> http://www.kickstarter.com/projects/adapteva/pa= rallella-a-supercomputer-for-everyone/
> In short, a multicore 32-bit risc cpu currently only used as a coproce= ssor.
> Not really a candidate for a port, but if it ever does get a full Linu= x,
> it might be interesting.
>
> > 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 madnes= s. In
> > other words, I think there's a lot more value in supporting d= iversity
> > on the embedded side than on the enterprise side.
>
> Power has a bit of the enterprise, too; it's got lower power usage= (vs
> x86, no comparisons with ARM I'm aware of), and currently holds th= e
> highest clock speed of any stock cpu.
> But I'd somehow expect embedded to be more open to a new libc than=
> enterprise; for the latter, we'd need either a big vendor using mu= sl
> or a distro (Debian/RHEL/SLES) using it...most likely in place of
> klibc / newlib / dietlibc, for static rescue tools or for the initrd.<= br> >
> Which reminds me...
> I've been in contact with someone working on a musl package for De= bian:
> https://github.com/wermut/= musl/
> He's currently looking for a sponsor/mentor, and has packaging tha= t is
> co-installable with libc6.
>
> Isaac Dunham
>

--047d7b33946dafe31f04e059f555--