From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2266 Path: news.gmane.org!not-for-mail From: John Spencer Newsgroups: gmane.linux.lib.musl.general Subject: Re: roadmap for 0.9.8 ? Date: Fri, 09 Nov 2012 16:36:47 +0100 Message-ID: <509D230F.5090404@barfooze.de> References: <5091B637.3060107@barfooze.de> <20121101000518.GG20323@brightrain.aerifal.cx> <20121108222452.GX20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1352475426 5927 80.91.229.3 (9 Nov 2012 15:37:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Nov 2012 15:37:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2267-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 09 16:37:16 2012 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 1TWqdv-0005Sn-DP for gllmg-musl@plane.gmane.org; Fri, 09 Nov 2012 16:37:15 +0100 Original-Received: (qmail 29904 invoked by uid 550); 9 Nov 2012 15:37:05 -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 29896 invoked from network); 9 Nov 2012 15:37:05 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Mail/1.0 In-Reply-To: <20121108222452.GX20323@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2266 Archived-At: 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 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.