Date: Fri, 09 Nov 2012 16:36:47 +0100 From: John Spencer <maillist-musl@...fooze.de> To: musl@...ts.openwall.com Subject: Re: roadmap for 0.9.8 ? 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.
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.