Re: roadmap for 0.9.8 ?

[John Spencer <maillist-musl@barfooze.de>]

On 11/08/2012 11:24 PM, Rich Felker wrote:
> - explicit mips soft-float abi support (mainly for use with broken
>>>     openwrt kernels) ,
>> Mainly this requires a discussion of whether it should go in the build
>> system (sub-archs/abis) or just at the source level somewhere.
> Still on the table for discussion.

i don't have an opinion on this, however:
for path names that are using $ARCH, such as the ld-musl files, it would 
be nice if for example mips and mipsel had different filenames (for 
multi-lib installations).
same applies for armv4tl vs armv7l, etc

>> Speaking of that, right now all uses of vfork are rather expensive
>> because we have to loop and check each signal to check that it doesn't
>> have a handler set. I'd like to make a global atomic bit array in
>> sigaction.c to store the set of signals which have ever had their
>> disposition set to a signal handling function. Then it would be easy
>> to loop over just that set when resetting, and in fact the resetting
>> code could be shared between different places that need it
>> (posix_spawn, system, popen, wordexp).
> This is another cleanup task which most people won't even see or
> appreciate (except perhaps in benchmarks), but I think I'll tackle it
> soon anyway.

oh, i think everyone appreciates faster / less memory-hungry code.

>>> additionally, i think it'd make sense to add stubs for the missing
>>> optional schedule functions (as most of them are already there),
>>> that way we could build some exotic programs like "fluidsynth"
>>> without patches, and further increase the pkgsrc success rate:
>> Hopefully we can just add real versions of them. A good half of the
> This is also on my agenda at high priority (pardon the pun).
will it make it into the next release ?
i think, for the moment, having it as stubs would perfectly suffice.

>>> - ppc port ?
>> Yes. Is anybody else up for doing the work integrating it, or should
>> I plan to do it myself? It'd be really nice to have somebody familiar
>> enough with the porting procedure to handle ports integration.
> No progress yet. I'd still be interested in mentoring somebody
> interested in doing this and/or other ports in hopes of getting to the
> point where we have a co-maintainer for ports. This person would not
> need to be an expert on musl internals, just familiar with asm, cross
> or native compiling for non-x86 archs, and basic debugging (strace/gdb
> usage), and would be the "go-to" person for arch-specific bug reports.

i guess the ppc port can be postponed.

>> One thing that comes to mind is updating the wiki and keeping it
>> relevant. Most of the FAQ items are obsolete now.
> Volunteers?
i cleaned up the obsolete stuff.

>> Perhaps something to address soon is the missing 'm' modifier in scanf
> Still pending. I'd like to do it before the next release.
>
>> An internal task I want to work on is removing most/all of the
>> #include directives from stdio_impl.h. I think this would improve
> Done. Also did pthread_impl.h. Much cleaner now.
nice, i especially like the memset removal in leaf-functions.
which could lead to what we discussed on IRC a while ago (object files 
that are identical for PIC and non-PIC should only be built once)
>> We could also work on more C11 features, like<uchar.h>  or C11
>> threads. C11 threads should just be a matter of making namespace-clean
> Pending. I'll probably hold off on this until the following release
> cycle.
yeah, that doesn't seem especially urgent.
>> I know you want some fixes/improvements in configure.
> Done.
thanks
>> Aside from that, I'd like this release cycle to be much shorter. The
>> changes we're looking at are a lot less invasive (compared to TLS) so
>> I'll feel comfortable releasing sooner rather than sitting around
>> waiting for bugs to pop up like the last release cycle.
> Being that we have some major improvements (dl_iterate_phdr and
> several show-stopping MIPS-specific bugs fixed), I'd like to aim to
> have the next release be made pretty soon.
*nod*
>   Please let me know if there
> are other issues that should be addressed before release.
everything that came to mind is fixed by now.