Proposed roadmap to 1.0

Proposed roadmap to 1.0

[Rich Felker]

Hi all,

Here is a VERY tentative, proposed roadmap towards a 1.0 release of
musl. Comments welcome!

Rich



0.9.11
Projected release: ASAP
No further goals at the moment except fixing additional bugs found.

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.

Re: Proposed roadmap to 1.0

[Rob Landley]

On 06/29/2013 06:50:41 PM, Rich Felker wrote:
> Hi all,
> 
> Here is a VERY tentative, proposed roadmap towards a 1.0 release of
> musl. Comments welcome!
> 
> Rich
> 
> 0.9.11
> Projected release: ASAP
> No further goals at the moment except fixing additional bugs found.
> 
> 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.

So this would be about the "feature complte for not-internationalized  
C99" level?

I'll try to get support into aboriginal linux for that release.

Rob

Re: Proposed roadmap to 1.0

[Rich Felker]

On Sat, Jun 29, 2013 at 09:53:29PM -0500, Rob Landley wrote:
> On 06/29/2013 06:50:41 PM, Rich Felker wrote:
> >Hi all,
> >
> >Here is a VERY tentative, proposed roadmap towards a 1.0 release of
> >musl. Comments welcome!
> >
> >Rich
> >
> >0.9.11
> >Projected release: ASAP
> >No further goals at the moment except fixing additional bugs found.
> >
> >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.
> 
> So this would be about the "feature complte for
> not-internationalized C99" level?

It should already be feature-complete for C99, except possibly some
bugs in the time stuff I want to overhaul. There are a few things
missing for POSIX (some new strftime field width stuff comes to mind),
but not much; probably a few more small details for XSI option in the
way of interfaces that nobody uses, like encrypt(). And some things
missing for C11, of course.

> I'll try to get support into aboriginal linux for that release.

Great! Yes, this sounds like a good target version for you, especially
since I'm hoping to swat a lot more bugs by then (see the hybrid audit
item above). It should also give us plenty of time to resolve any
issues you encounter using musl with aboriginal between then and musl
1.0 so that everything is really polished when we get to 1.0.

Rich

Re: Proposed roadmap to 1.0

[Isaac]

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.
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.
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).
hppa and alpha are most interesting for a computer historian.
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.

Isaac Dunham

Re: Proposed roadmap to 1.0

[Rich Felker]

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. 
> 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.

> 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.

> 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.

> 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.

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...

> 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.

Rich

Re: Proposed roadmap to 1.0

[Strake]

On 29/06/2013, Rich Felker <dalias@aerifal.cx> 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.

MMIX!

Re: Proposed roadmap to 1.0

[Isaac]

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

> 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

Re: Proposed roadmap to 1.0

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 5092 bytes --]

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 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
>

[-- Attachment #2: Type: text/html, Size: 6853 bytes --]

Re: Proposed roadmap to 1.0

[Rob Landley]

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

Re: Proposed roadmap to 1.0

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2013-06-30 01:34:09 -0400]:
> On Sat, Jun 29, 2013 at 10:20:45PM -0700, Isaac wrote:
> > m32r is live, but I'm not aware of much interest.
> > tilera and epiphany (the Parallela coprocessor) sound interesting,
> 
> 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 assume for servers x32 (small address space, but many registers)
and aarch64 (low power) can be still relevant

Re: Proposed roadmap to 1.0

[Rich Felker]

On Sun, Jun 30, 2013 at 08:21:25AM +0100, Justin Cormack wrote:
> > > > 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.

Are you talking about AIX or a build of Linux they ship? My guess
would be they're just not shipping 32-bit libs, which wouldn't really
make any difference if your intent is to use a musl ecosystem instead.
If it's 32-bit support turned off in the kernel (is that even
possible?), that could also easily be turned back on.

> 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.

You can also run 32-bit userspace on MIPS64. However if you want to do
this, the n32 ABI (analogous to x32 on x86_64) is moderately more
efficient and less ugly.

So I agree MIPS n32 and maybe also n64 are interesting to support.

Rich

Re: Proposed roadmap to 1.0

[Luca Barbato]

On 06/30/2013 12:45 PM, Szabolcs Nagy wrote:
 > i assume for servers x32 (small address space, but many registers)

x32 is sort of underperforming last time it was discussed.

> and aarch64 (low power) can be still relevant

we could throw in the pot bfin, but I'm not sure if it is worth the hassle.

lu

Re: Proposed roadmap to 1.0

[Rob Landley]

On 06/30/2013 01:42:48 AM, Isaac wrote:
> On Sun, Jun 30, 2013 at 01:34:09AM -0400, Rich Felker wrote:
> > > 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.

I'm still trying to fluff out  
http://landley.net/aboriginal/architectures.html and even if I don't  
describe half the Linux architectures I interrogated git to get a list  
of when each one was added. Might be useful.

> > 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.

Half the game consoles out there are Power. (Dunno about the current  
generation.) Back when Praystation 3 supported Linux built-in, it was  
the cheapest way to get a 64 bit PPC system with the Cell processor  
stuff. (Which alas never took off because it was way too hard to  
program and they were just proprietary enough in the programming info  
to prevent open source people from ever quite managing to care. These  
days Hexagon has all the "3D rendering in software" buzz they used to  
brag about, but that's problematic to get a test environment working  
too...)

Rob

Re: Proposed roadmap to 1.0

[Rob Landley]

On 06/30/2013 02:21:25 AM, Justin Cormack wrote:
> MIPS64 would be nice as the Chinese are making them (Loongson) for  
> general
> use.

My mips64 target in aboriginal doesn't work, and hasn't worked for a  
longish time. Going back and running the old images doesn't work  
either, so I think qemu changed out from under me and I didn't notice.  
(Sparc did the same thing but I managed to -cpu "stop that" workaround  
for that.)

Do you know where I can get a mips64 test environment? (Debian iso or  
something that boots under qemu?)

Rob

Re: Proposed roadmap to 1.0

[Rob Landley]

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

Re: Proposed roadmap to 1.0

[Isaac]

On Thu, Jul 04, 2013 at 01:13:52PM -0500, Rob Landley wrote:
> On 06/30/2013 02:21:25 AM, Justin Cormack wrote:
> >MIPS64 would be nice as the Chinese are making them (Loongson) for
> >general
> >use.
> 
> My mips64 target in aboriginal doesn't work, and hasn't worked for a
> longish time. Going back and running the old images doesn't work
> either, so I think qemu changed out from under me and I didn't
> notice. (Sparc did the same thing but I managed to -cpu "stop that"
> workaround for that.)
> 
> Do you know where I can get a mips64 test environment? (Debian iso
> or something that boots under qemu?)
> 
Here's Debian's "netinst" CD for big-endian mips:
http://cdimage.debian.org/debian-cd/current/mips/iso-cd/debian-7.1.0-mips-netinst.iso

And here are Squeeze and Lenny mips images (use -M malta).
http://people.debian.org/~aurel32/qemu/mips/

HTH,
Isaac Dunham

Re: Proposed roadmap to 1.0

[Isaac]

On Thu, Jul 04, 2013 at 01:10:10PM -0500, Rob Landley wrote:
> On 06/30/2013 01:42:48 AM, Isaac wrote:
> >On Sun, Jun 30, 2013 at 01:34:09AM -0400, Rich Felker wrote:
> >> > 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.
> 
> I'm still trying to fluff out
> http://landley.net/aboriginal/architectures.html and even if I don't
> describe half the Linux architectures I interrogated git to get a
> list of when each one was added. Might be useful.
> 
> >> 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.
> 
> Half the game consoles out there are Power. (Dunno about the current
> generation.) Back when Praystation 3 supported Linux built-in, it
> was the cheapest way to get a 64 bit PPC system with the Cell
> processor stuff. (Which alas never took off because it was way too

Last generation was entirely Power (XBox and PS3 were Cell, Nintendo was PPC,
I forget who else was relevant), but next generation XBox and PS4 are AMD 
(64bit x86).

Thanks,
Isaac Dunham

Re: Proposed roadmap to 1.0

[Rich Felker]

On Sat, Jun 29, 2013 at 07:50:41PM -0400, Rich Felker wrote:
> 0.9.11
> Projected release: ASAP
> No further goals at the moment except fixing additional bugs found.

Done.

> 0.9.12
> Projected release: Mid to late July
> Key targets:
> - Overhaul of time handling, including zoneinfo support.

Done, but may need further testing before thinking about release.

> - Overhaul resolver to better provide legacy APIs without code dup.

I haven't started looking at this again yet. If I don't get to it soon
I would not mind pushing it back since I'd rather keep momentum of the
release schedule than meet every single goal. But I don't think it's
particularly hard either.

> - Hybrid automatic/manual audit for cruft and code smells.

Any suggestions on techniques to use here?

> - Resolve symlink direction issue for dynamic linker.

This issue has been around way too long. I really want it fixed for
the next release. Any ideas on how to best allow "make install"
without permissions or overriding $syslibdir? The idea is I want it to
be possible to install a _development_ environment in a user-writable
$prefix that generates binaries whose PT_INTERP is the standard
/lib/ld-musl-$(ARCH).so.1. This would not be a working runtime
environment, of course. If I recall, we had some decent ideas before;
maybe I should look back at them.

> - Affinity/cpuset interfaces.

Last time I started working on this, I got sick of it before I got
very far. There are just so many tedious macros/inline-functions to
implement. I was also frustrated with having to put so much code in a
public header. For this, I'd really like some help on both:

- ideas for making it less hideous, and
- actually writing it out.

With the above in mind, I think we're mostly on schedule for the
release roadmap. And we might be partly ahead of schedule on other
items:

> 0.9.13
> Projected release: Early August
> Key targets:
> [...]
> - Establish formal procedure for regression testing.

nsz is working on the test package which looks like it includes some
regression testing already.

Rich

Re: Proposed roadmap to 1.0

[orc]

[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]

On Sat, 29 Jun 2013 19:50:41 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> Hi all,
> 
> Here is a VERY tentative, proposed roadmap towards a 1.0 release of
> musl. Comments welcome!
> 
> Rich
> 
> 
> 
> 0.9.11
> Projected release: ASAP
> No further goals at the moment except fixing additional bugs found.
> 
> 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.

Hi Rich,

(This probably should go into 1.0 wishlist thread, but this one
freshier)

While building a file server/router I found some bugs/incompatibilities
in getaddrinfo() and getifaddrs().

getaddrinfo() does not reports IPv6 available when asked with
AF_UNSPEC. Thus, servers like openssh or tinc (vpn daemon) still bind
only IPv4 socket when they configured to bind IPv4 and IPv6 sockets.
getifaddrs() does not returns AF_PACKET like glibc does, so list of
all system interfaces is incomplete (does not shows inactive
interfaces).

I attached patch for getaddrinfo() (adopt it if you need it)
and test program. I still have no any clues about getifaddrs(), but
that is not critical. It is usually implemented with help of netlink
(and possibly there is no other way, maybe some /proc file will give a
list)

musl-git (from 0.9.10 release). Unfortunately your git interface and
website were down at the time this email written and I cannot see any
changes in getaddrinfo.c from that version now.
I checked
https://github.com/idunham/musl/blob/master/src/network/getaddrinfo.c,
it seems to be same.

If I am missed something, let me know.

[-- Attachment #2: gai-test.c --]
[-- Type: application/octet-stream, Size: 710 bytes --]

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>

int main(void)
{
	struct addrinfo *ai, *aip, hint = {0};
	int err;
	char hostn[256], portn[10];

	hint.ai_family = AF_UNSPEC;
	hint.ai_socktype = SOCK_STREAM;
	hint.ai_protocol = IPPROTO_TCP;
	hint.ai_flags = AI_PASSIVE;

	err = getaddrinfo(NULL, "22", &hint, &ai);
	if (err || !ai) return 1;

	for (aip = ai; aip; aip = aip->ai_next) {
		err = getnameinfo(aip->ai_addr, aip->ai_addrlen, hostn, sizeof(hostn), portn, sizeof(portn), NI_NUMERICHOST|NI_NUMERICSERV);
		if (err) { printf("%p: invalid\n", aip); continue; }
		printf("%p: %s:%s\n", aip, hostn, portn);
	}

	freeaddrinfo(ai);

	return 0;
}

[-- Attachment #3: musl-0.9.10git-getaddrinfo-ipv4-ipv6.patch --]
[-- Type: application/octet-stream, Size: 1561 bytes --]

--- musl/src/network/getaddrinfo.c.orig
+++ musl/src/network/getaddrinfo.c
@@ -100,23 +100,31 @@
 	}
 
 	if (!host) {
-		if (family == AF_UNSPEC) family = AF_INET;
-		buf = calloc(sizeof *buf, 1+EXTRA);
+		int unspec = 0, idx = 0;
+		if (family == AF_UNSPEC) { unspec = 1; family = AF_INET; }
+		buf = calloc(sizeof *buf, (unspec ? 2 : 1)+EXTRA);
 		if (!buf) return EAI_MEMORY;
-		buf->ai.ai_protocol = proto;
-		buf->ai.ai_socktype = type;
-		buf->ai.ai_addr = (void *)&buf->sa;
-		buf->ai.ai_addrlen = family==AF_INET6 ? sizeof sa.sin6 : sizeof sa.sin;
-		buf->ai.ai_family = family;
-		buf->sa.sin.sin_family = family;
-		buf->sa.sin.sin_port = port;
+_next6:
+		(buf+idx)->ai.ai_protocol = proto;
+		(buf+idx)->ai.ai_socktype = type;
+		(buf+idx)->ai.ai_addr = (void *)&(buf+idx)->sa;
+		(buf+idx)->ai.ai_addrlen = family==AF_INET6 ? sizeof sa.sin6 : sizeof sa.sin;
+		(buf+idx)->ai.ai_family = family;
+		(buf+idx)->sa.sin.sin_family = family;
+		(buf+idx)->sa.sin.sin_port = port;
+		if (unspec) (buf+idx)->ai.ai_next = &(buf+1)->ai;
 		if (!(flags & AI_PASSIVE)) {
 			if (family == AF_INET) {
-				0[(uint8_t*)&buf->sa.sin.sin_addr.s_addr]=127;
-				3[(uint8_t*)&buf->sa.sin.sin_addr.s_addr]=1;
-			} else buf[0].sa.sin6.sin6_addr.s6_addr[15] = 1;
+				0[(uint8_t*)&(buf+idx)->sa.sin.sin_addr.s_addr]=127;
+				3[(uint8_t*)&(buf+idx)->sa.sin.sin_addr.s_addr]=1;
+			} else (buf+idx)[0].sa.sin6.sin6_addr.s6_addr[15] = 1;
 		}
 		*res = &buf->ai;
+		if (unspec) {
+			idx = 1; unspec = 0;
+			family = AF_INET6;
+			goto _next6;
+		}
 		return 0;
 	}
 

Re: Proposed roadmap to 1.0

[Rich Felker]

On Wed, Jul 24, 2013 at 10:14:10PM +0800, orc wrote:
> While building a file server/router I found some bugs/incompatibilities
> in getaddrinfo() and getifaddrs().
> 
> getaddrinfo() does not reports IPv6 available when asked with
> AF_UNSPEC. Thus, servers like openssh or tinc (vpn daemon) still bind
> only IPv4 socket when they configured to bind IPv4 and IPv6 sockets.

Indeed, this is an oversight.

> getifaddrs() does not returns AF_PACKET like glibc does, so list of
> all system interfaces is incomplete (does not shows inactive
> interfaces).

Is there a use case you want this for? I remember when we added
getifaddrs this was discussed, and I was hesitant to add AF_PACKET
because it's using some deprecated version of some structure where the
fields are too small to store the values they're supposed to
represent. I'd have to look through the mailing list and/or IRC logs
to recall the details, though. I'm not entirely opposed to it if
there's a serious need, but at the time it seemed like a poorly
designed interface.

> I attached patch for getaddrinfo() (adopt it if you need it)
> and test program.

I think it could be cleaner/simpler but I might just commit it as-is
for now and wait to clean it up until the getaddrinfo cleanup/overhaul
which was scheduled for this release cycle but will get pushed back to
the next.

> I still have no any clues about getifaddrs(), but
> that is not critical. It is usually implemented with help of netlink
> (and possibly there is no other way, maybe some /proc file will give a
> list)

musl's is entirely based on /proc because the netlink stuff is
undocumented, seemed really bloated, and I didn't want to risk pulling
in code that was inadvertently derived from GNU code.

Rich

Re: Proposed roadmap to 1.0

[orc]

On Wed, 24 Jul 2013 10:42:45 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Wed, Jul 24, 2013 at 10:14:10PM +0800, orc wrote:
> > While building a file server/router I found some
> > bugs/incompatibilities in getaddrinfo() and getifaddrs().
> > 
> > getaddrinfo() does not reports IPv6 available when asked with
> > AF_UNSPEC. Thus, servers like openssh or tinc (vpn daemon) still
> > bind only IPv4 socket when they configured to bind IPv4 and IPv6
> > sockets.
> 
> Indeed, this is an oversight.
> 
> > getifaddrs() does not returns AF_PACKET like glibc does, so list of
> > all system interfaces is incomplete (does not shows inactive
> > interfaces).
> 
> Is there a use case you want this for? I remember when we added
> getifaddrs this was discussed, and I was hesitant to add AF_PACKET
> because it's using some deprecated version of some structure where the
> fields are too small to store the values they're supposed to
> represent. I'd have to look through the mailing list and/or IRC logs
> to recall the details, though. I'm not entirely opposed to it if
> there's a serious need, but at the time it seemed like a poorly
> designed interface.

I faced problem when I tried to build dhcpcd with musl. I
dropped dhcpcd then, found simple default.script for udhcpc and forgot
about any problems.

> 
> > I attached patch for getaddrinfo() (adopt it if you need it)
> > and test program.
> 
> I think it could be cleaner/simpler but I might just commit it as-is
> for now and wait to clean it up until the getaddrinfo cleanup/overhaul
> which was scheduled for this release cycle but will get pushed back to
> the next.

Thanks for review. I think I can apply it now on server :)

> 
> > I still have no any clues about getifaddrs(), but
> > that is not critical. It is usually implemented with help of netlink
> > (and possibly there is no other way, maybe some /proc file will
> > give a list)
> 
> musl's is entirely based on /proc because the netlink stuff is
> undocumented, seemed really bloated, and I didn't want to risk pulling
> in code that was inadvertently derived from GNU code.

I tried already netlink and dropped it since udhcpc works nicely. I 
really agree that it is too opaque.

> 
> Rich

Re: Proposed roadmap to 1.0

[Rich Felker]

On Wed, Jul 24, 2013 at 11:29:42PM +0800, orc wrote:
> > > getifaddrs() does not returns AF_PACKET like glibc does, so list of
> > > all system interfaces is incomplete (does not shows inactive
> > > interfaces).
> > 
> > Is there a use case you want this for? I remember when we added
> > getifaddrs this was discussed, and I was hesitant to add AF_PACKET
> > because it's using some deprecated version of some structure where the
> > fields are too small to store the values they're supposed to
> > represent. I'd have to look through the mailing list and/or IRC logs
> > to recall the details, though. I'm not entirely opposed to it if
> > there's a serious need, but at the time it seemed like a poorly
> > designed interface.
> 
> I faced problem when I tried to build dhcpcd with musl. I
> dropped dhcpcd then, found simple default.script for udhcpc and forgot
> about any problems.

Do you know what dhcpcd needs it for? If it's just automatic binding
when you don't specify an interface, that's probably a bad idea
anyway... But maybe we should support it.

> > > I attached patch for getaddrinfo() (adopt it if you need it)
> > > and test program.
> > 
> > I think it could be cleaner/simpler but I might just commit it as-is
> > for now and wait to clean it up until the getaddrinfo cleanup/overhaul
> > which was scheduled for this release cycle but will get pushed back to
> > the next.
> 
> Thanks for review. I think I can apply it now on server :)

I didn't really "review" it, but as long as you tested it, it's
probably fine. There are only 3 possible code paths here, not an
infinite family of them, so as long as each of the 3 works for you
it should be fine.

Rich

Re: Proposed roadmap to 1.0

[orc]

On Wed, 24 Jul 2013 12:04:09 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Wed, Jul 24, 2013 at 11:29:42PM +0800, orc wrote:
> > > > getifaddrs() does not returns AF_PACKET like glibc does, so
> > > > list of all system interfaces is incomplete (does not shows
> > > > inactive interfaces).
> > > 
> > > Is there a use case you want this for? I remember when we added
> > > getifaddrs this was discussed, and I was hesitant to add AF_PACKET
> > > because it's using some deprecated version of some structure
> > > where the fields are too small to store the values they're
> > > supposed to represent. I'd have to look through the mailing list
> > > and/or IRC logs to recall the details, though. I'm not entirely
> > > opposed to it if there's a serious need, but at the time it
> > > seemed like a poorly designed interface.
> > 
> > I faced problem when I tried to build dhcpcd with musl. I
> > dropped dhcpcd then, found simple default.script for udhcpc and
> > forgot about any problems.
> 
> Do you know what dhcpcd needs it for? If it's just automatic binding
> when you don't specify an interface, that's probably a bad idea
> anyway... But maybe we should support it.

It listed interfaces internally, compared command line argument with
each, and if not found, exited with error. An interface of question was
down at the moment, so was not listed by getifaddrs().

> 
> > > > I attached patch for getaddrinfo() (adopt it if you need it)
> > > > and test program.
> > > 
> > > I think it could be cleaner/simpler but I might just commit it
> > > as-is for now and wait to clean it up until the getaddrinfo
> > > cleanup/overhaul which was scheduled for this release cycle but
> > > will get pushed back to the next.
> > 
> > Thanks for review. I think I can apply it now on server :)
> 
> I didn't really "review" it, but as long as you tested it, it's
> probably fine. There are only 3 possible code paths here, not an
> infinite family of them, so as long as each of the 3 works for you
> it should be fine.

OK, just to be sure. I tested it in 3 possible ways, anything works
nice.

> 
> Rich

Re: Proposed roadmap to 1.0

[Rob Landley]

On 07/17/2013 11:02:05 AM, Rich Felker wrote:
> > - Affinity/cpuset interfaces.
> 
> Last time I started working on this, I got sick of it before I got
> very far. There are just so many tedious macros/inline-functions to
> implement. I was also frustrated with having to put so much code in a
> public header. For this, I'd really like some help on both:
> 
> - ideas for making it less hideous, and
> - actually writing it out.

For toybox I ignored the glibc interfaces and just used the raw  
syscall, manipulating the arguments myself with bit shifts. Let's see...

Wow the man 3 CPU_SET macros are crazy. Very first one, CPU_ZERO() does  
not specify the size of the array. So how does it determine it? It's  
gotta be getting it from cpu_set_t which is defined in  
/usr/include/*/bits/sched.h:

   /* Data structure to describe CPU mask.  */
   typedef struct
   {
     __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS];
   } cpu_set_t;

So what's _NCPUBITS?

   /* Size definition for CPU sets.  */
   # define __CPU_SETSIZE  1024
   # define __NCPUBITS     (8 * sizeof (__cpu_mask))

   /* Type for array elements in 'cpu_set_t'.  */
   typedef unsigned long int __cpu_mask;

So... it's hardwired to 1024 cpus.

I don't think there _is_ a way to make this non-ugly. What actually  
uses this?

Rob

Re: Proposed roadmap to 1.0

[Rich Felker]

On Thu, Jul 25, 2013 at 12:25:06AM +0800, orc wrote:
> > > I faced problem when I tried to build dhcpcd with musl. I
> > > dropped dhcpcd then, found simple default.script for udhcpc and
> > > forgot about any problems.
> > 
> > Do you know what dhcpcd needs it for? If it's just automatic binding
> > when you don't specify an interface, that's probably a bad idea
> > anyway... But maybe we should support it.
> 
> It listed interfaces internally, compared command line argument with
> each, and if not found, exited with error. An interface of question was
> down at the moment, so was not listed by getifaddrs().

OK, this is just gratuitous brokenness/non-portability. if_nametoindex
can be used to check whether an interface name is valid, and
if_nameindex gives you a list of all interfaces.

Rich

Re: Proposed roadmap to 1.0

[Rich Felker]

On Wed, Jul 24, 2013 at 01:36:53PM -0500, Rob Landley wrote:
> On 07/17/2013 11:02:05 AM, Rich Felker wrote:
> >> - Affinity/cpuset interfaces.
> >
> >Last time I started working on this, I got sick of it before I got
> >very far. There are just so many tedious macros/inline-functions to
> >implement. I was also frustrated with having to put so much code in a
> >public header. For this, I'd really like some help on both:
> >
> >- ideas for making it less hideous, and
> >- actually writing it out.
> 
> For toybox I ignored the glibc interfaces and just used the raw
> syscall, manipulating the arguments myself with bit shifts. Let's
> see...
> 
> Wow the man 3 CPU_SET macros are crazy. Very first one, CPU_ZERO()
> does not specify the size of the array. So how does it determine it?
> It's gotta be getting it from cpu_set_t which is defined in
> /usr/include/*/bits/sched.h:

There's a new set of macros, all ending in _S, which take an
additional size argument. However the size is in bytes and it's
unclear to me how the caller is supposed to know the required
alignment (e.g. making a 3-byte set would not be valid).

>   /* Data structure to describe CPU mask.  */
>   typedef struct
>   {
>     __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS];
>   } cpu_set_t;
> 
> So what's _NCPUBITS?
> 
>   /* Size definition for CPU sets.  */
>   # define __CPU_SETSIZE  1024
>   # define __NCPUBITS     (8 * sizeof (__cpu_mask))
> 
>   /* Type for array elements in 'cpu_set_t'.  */
>   typedef unsigned long int __cpu_mask;
> 
> So... it's hardwired to 1024 cpus.
> 
> I don't think there _is_ a way to make this non-ugly. What actually
> uses this?

That was my question about the whole affinity system in general. My
view is that it's stupid micro-management of scheduling that should be
done by the kernel, and that if the kernel's not doing a good enough
job of managing which cpu a task runs on, the kernel scheduler should
be fixed rather than adding hacks in apps.

With that said, affinity is useful for debugging certain race
conditions that are easier to hit on single-core.

Rich

Re: Proposed roadmap to 1.0

[Daniel Cegiełka]

2013/7/24 Rich Felker <dalias@aerifal.cx>:

>
> That was my question about the whole affinity system in general. My
> view is that it's stupid micro-management of scheduling that should be
> done by the kernel, and that if the kernel's not doing a good enough
> job of managing which cpu a task runs on, the kernel scheduler should
> be fixed rather than adding hacks in apps.

Not always. Sometimes the kernel scheduler isn't the solution and you
care about isolating applications from the kernel/os. How do you do it
without this feature?

http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html

musl is a very good candidate for use in HPC, so this functionality
would be very valuable.

Daniel

Re: Proposed roadmap to 1.0

[Rich Felker]

On Thu, Jul 25, 2013 at 09:25:39AM +0200, Daniel Cegiełka wrote:
> 2013/7/24 Rich Felker <dalias@aerifal.cx>:
> 
> >
> > That was my question about the whole affinity system in general. My
> > view is that it's stupid micro-management of scheduling that should be
> > done by the kernel, and that if the kernel's not doing a good enough
> > job of managing which cpu a task runs on, the kernel scheduler should
> > be fixed rather than adding hacks in apps.
> 
> Not always. Sometimes the kernel scheduler isn't the solution and you
> care about isolating applications from the kernel/os. How do you do it
> without this feature?
> 
> http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html

It's a nice article and I don't have data to argue with its assessment
of the current bottlenecks, but I disagree with the philosophy that
the solution is to bypass the kernel, in much the same way that I
disagree with the philosophy (of APR, glib, gnulib, etc.) that when
the libc is broken you should bypass the libc. My philosophy is that
if the libc is broken, you should fix the libc, and if the kernel is
broken (which it is, in many ways, especially when it comes to having
too much bloated abstraction in the wrong places, not enough in the
right places, and way too much need for synchronization), then you
should fix the kernel. Admittedly that's not an easy task, and I
should probably shut up until/unless I'm willing to do it.

> musl is a very good candidate for use in HPC, so this functionality
> would be very valuable.

I don't disagree with that. Despite my dislike for the whole affinity
system, I've deemed it important enough to be a big 1.0 roadmap item.
:-)

Rich

Re: Proposed roadmap to 1.0

[Timo Teras]

On Wed, 24 Jul 2013 13:36:53 -0500
Rob Landley <rob@landley.net> wrote:

> On 07/17/2013 11:02:05 AM, Rich Felker wrote:
> > > - Affinity/cpuset interfaces.
> > 
> > Last time I started working on this, I got sick of it before I got
> > very far. There are just so many tedious macros/inline-functions to
> > implement. I was also frustrated with having to put so much code in
> > a public header. For this, I'd really like some help on both:
> > 
> > - ideas for making it less hideous, and
> > - actually writing it out.
> 
> For toybox I ignored the glibc interfaces and just used the raw  
> syscall, manipulating the arguments myself with bit shifts. Let's
> see...
> 
> Wow the man 3 CPU_SET macros are crazy. Very first one, CPU_ZERO()
> does not specify the size of the array. So how does it determine it?
> It's gotta be getting it from cpu_set_t which is defined in  
> /usr/include/*/bits/sched.h:
> 
>    /* Data structure to describe CPU mask.  */
>    typedef struct
>    {
>      __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS];
>    } cpu_set_t;
> 
> So what's _NCPUBITS?
> 
>    /* Size definition for CPU sets.  */
>    # define __CPU_SETSIZE  1024
>    # define __NCPUBITS     (8 * sizeof (__cpu_mask))
> 
>    /* Type for array elements in 'cpu_set_t'.  */
>    typedef unsigned long int __cpu_mask;
> 
> So... it's hardwired to 1024 cpus.
> 
> I don't think there _is_ a way to make this non-ugly. What actually  
> uses this?

Seems also many SMP-aware programs use sched_getaffinity to figure out
how many threads to launch. Including, but not limited to, util-linux
(nproc) and gccgo. Most should autodetect this, but gccgo seems to just
unconditionally use it.

Speaking of gccgo, it seems that gcc 4.8.1 without any changes does not
compile with musl due to:
- libgo/mksysinfo.sh: conflicting kernel and libc #includes
- libgo/runtime/getncpu-linux.c: uses sched_getaffinity + cpu_set_t
- libgo/runtime/proc.c: uses make/swap/getcontext, and needs configure
  to detect if TLS segment register (fs/gs on x86) is part of the
  context or not

The first two can be patched easily. But lack of *context is a stopper.
I think I'll need the *context for few other projects as well...

- Timo

Re: Proposed roadmap to 1.0

[Rob Landley]

On 07/24/2013 02:47:19 PM, Rich Felker wrote:
> > So... it's hardwired to 1024 cpus.
> >
> > I don't think there _is_ a way to make this non-ugly. What actually
> > uses this?
> 
> That was my question about the whole affinity system in general. My
> view is that it's stupid micro-management of scheduling that should be
> done by the kernel, and that if the kernel's not doing a good enough
> job of managing which cpu a task runs on, the kernel scheduler should
> be fixed rather than adding hacks in apps.

There are arguments in favor of it, mostly realtime and userspace power  
management. That said, the only thing that _needs_ to use this stuff is  
taskset, and everything else can get called _by_ taskset. Toybox  
implements taskset doesn't use anything out of libc to do so: syscall  
wrappers and managing its own data structures.

Still, you presumably want to build an unmodified util-linux and  
busybox.

The important thing isn't what glibc does, it's what the man pages say.  
I often start by implementing what the documentation says,  
building/running real packages, and then submitting bug reports against  
the docs.

The sched_getaffinity() and sched_setaffinity() syscall wrappers seem  
obvious, and then the _S versions of the macros. Round each size up to  
the next sizeof(long) bytes. That's pretty much the "should implement  
this, push patches upstream to make things use 'em" level.

man 3 CPU_SET says:

   CPU_ALLOC() CPU_FREE()
   CPU_ALLOC_SIZE() // trivial
   CPU_ZERO_S() CPU_SET_S() CPU_CLR_S() CPU_ISSET_S() CPU_COUNT_S()
   CPU_AND_S() CPU_OR_S() CPU_XOR_S() CPU_EQUAL_S()

That set isn't _that_ disgusting. CPU_ALLOC_SIZE(size) is just  
(((((size+7)/8)+3)/4)*4 which makes CPU_ALLOC(size) just be  
malloc(CPU_ALLOC_SIZE(size)) and CPU_FREE(x) is just free(x), and then  
CPU_ZERO_S(size, set) becomes memset(set, 0, size)... I've posted the  
set/isset equations here before, and/or/xor are just a for loop where  
CPU_AND_S(size, dest, src1, src2) is just "do {unsigned __i = size/4;  
while (__i) {dest[__i] = src1[__i] && src2[__i]; __i--;} } while (0)"  
or similar, for CPU_COUNT_S you can just cheat and do a bitwise loop  
with isset (this ain't performance critical)...

If you're bored, you could then make the non-S versions can be macros  
that call the _S versions with a hardwired CPU_SETSIZE argument, and  
obviously that's #defined to 1024. But "don't use deprecated  
interfaces" is also a reasonably response. (If ever there's a reason to  
NOT define stuff unless you #define GNU_DAMMIT it would be the non-S  
versions of these macros. #ifdef GNU_BRAIN_DAMAGE...)

It's evil, but not _that_ evil...

Rob