From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2254 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: roadmap for 0.9.8 ? Date: Thu, 8 Nov 2012 17:24:52 -0500 Message-ID: <20121108222452.GX20323@brightrain.aerifal.cx> References: <5091B637.3060107@barfooze.de> <20121101000518.GG20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1352413506 5692 80.91.229.3 (8 Nov 2012 22:25:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Nov 2012 22:25:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2255-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 08 23:25: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 1TWaXB-0001Mg-Ev for gllmg-musl@plane.gmane.org; Thu, 08 Nov 2012 23:25:13 +0100 Original-Received: (qmail 14057 invoked by uid 550); 8 Nov 2012 22:25:04 -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 14049 invoked from network); 8 Nov 2012 22:25:04 -0000 Content-Disposition: inline In-Reply-To: <20121101000518.GG20323@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2254 Archived-At: Some updates; hoping to do a release again soon... On Wed, Oct 31, 2012 at 08:05:19PM -0400, Rich Felker wrote: > > - dl_iterate_phdr() - looks as if this is currently cooking, and > > possibly an important bit to improve libgcc support, > > I'm planning to get this done in the next 48 hours. Will libgcc This goal was met; done. > > - 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. > 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. > > 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). > > - 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. > One thing that comes to mind is updating the wiki and keeping it > relevant. Most of the FAQ items are obsolete now. Volunteers? > 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. > 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. > I know you want some fixes/improvements in configure. Done. > 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. Please let me know if there are other issues that should be addressed before release. Rich