Date: Sun, 30 Jun 2013 04:24:10 -0500 From: Rob Landley <rob@...dley.net> To: musl@...ts.openwall.com Cc: musl@...ts.openwall.com Subject: Re: Proposed roadmap to 1.0 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 > 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. Yup, qemu has fairly good support for it, klibc supports it, and I got a debian iso to boot under it once (and then be unusable because curses was misconfigured for the console type, but it ran). Between the three I should be able to cobble something up. In general, if klibc, qemu, and my old toolchain support something, I'm interested in getting basic musl support for it. May take a while, 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. > > 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 poking register 0x18 (which makes qemu abort if you read from it, which is just sad)... > > 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. The only sparc target I ever actually got working was sparc32. And the recent openbios upgrade means it hangs as soon as interrupts are enabled under qemu 1.5. But it should be fixable... > > 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. qemu doesn't have decent support for it yet. Upstream qemu does coldfire (a nommu m68k subset). There's a fork that tries to emulate the mmu, but the kernel panics as soon as it tries to enable page tables. I've been poking... Laurent Vivier is it? I'd have to look it up and it's 4am here... It's on the todo list, but that requires qemu upgrades. > > 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. All the ppc images I've seen do 32 bit userspace under 64 bit kernels. The only architecture that really seems to make a committment to 64 bit 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 copy.) > > 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). > > hppa and alpha are most interesting for a computer historian. > > 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 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 Compaq didn't make processors it let the Alpha design team go, and AMD snapped them up and had them design the Athlon, and later the Opteron. (That's why it plugs into the Alpha's ev6 bus.) I consider supporting it about on par with supporting m68k, it's a historically important chip and a reasonably nice design, now obsolete but still well supported by hobbyists who remember it fondly. Unfortunately, it has the same qemu problem that m68k does: application emulation is there but system emulation doesn't do the MMU right. (I'm 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. > > 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 http://landley.net/aboriginal/architectures.html but the research is ongoing. (Bits of that page trail off in midsentence...) My problem is when I get started on computer history I blather at huge length. Still, the "when support was added for each architecture" list might be useful as a frame of reference... > Rich Rob
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.