From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2235 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: roadmap for 0.9.8 ? Date: Wed, 31 Oct 2012 20:05:19 -0400 Message-ID: <20121101000518.GG20323@brightrain.aerifal.cx> References: <5091B637.3060107@barfooze.de> 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 1351728330 8191 80.91.229.3 (1 Nov 2012 00:05:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Nov 2012 00:05:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2236-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 01 01:05:40 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 1TTiHz-000685-3B for gllmg-musl@plane.gmane.org; Thu, 01 Nov 2012 01:05:39 +0100 Original-Received: (qmail 25684 invoked by uid 550); 1 Nov 2012 00:05:30 -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 25670 invoked from network); 1 Nov 2012 00:05:30 -0000 Content-Disposition: inline In-Reply-To: <5091B637.3060107@barfooze.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2235 Archived-At: On Thu, Nov 01, 2012 at 12:37:27AM +0100, John Spencer wrote: > i was thinking about what will go into the next release... > > open positions that were originally intended to go into 0.9.7 are, > as taken from the latest "pending for release" mails: > > - 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 automatically use dl_iterate_phdr once it's added, or is there some hard-coded glibc-specific logic we need to check in the -linux-musl target patches for gcc? > - 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. > - wordexp ? It's no hurry since this is a crap interface nobody uses anyway, but I would like to update it to use vfork, possibly by making it use posix_spawn rather than duplicating the functionality. I would use popen, which in many ways seems like the more natural choice, but that requires transforming the argument into an appropriate escaped form and allocating a temporary string for it. 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). > - subarchs in build system (e.g. mips-softfloat, arm-hardfloat, etc.), Yes, this mainly requires some thinking (or experimenting) to see what the real requirements are. > - nsz' suggested math improvements ? > > 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 effort of doing these is going to be just checking that we get all the files added right, so from that standpoint we might as well just do it all in one step rather than having to go back and make sure we get everything right later when we fill them out. I don't think there are any more spinlocks or other things that would make problems in priority-enabled applications. > - 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. > is there something else i missed, and what are your plans ? Yeah, I was pretty tired when I pushed the last release out; that's why it wasn't accompanied by a development direction paragraph. One thing that comes to mind is updating the wiki and keeping it relevant. Most of the FAQ items are obsolete now. Perhaps something to address soon is the missing 'm' modifier in scanf (POSIX extension for malloc'ing strings rather than using caller-provided buffers). 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 compile time noticably. But it will not add any functionality, of course. We could also work on more C11 features, like or C11 threads. C11 threads should just be a matter of making namespace-clean aliases for the pthread functions and wrapping those with thrd_* names. However, for the enums we might need to wait for glibc folks to assign values. I know you want some fixes/improvements in configure. 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. > besides of musl itself, i think it would be a nice achievement if we > could get the microblaze toolchain patches integrated in the > upstream repos (or at least patches against current gcc/binutils > trees), so that we distro-builders dont need to special-case for > microblaze. Yes, I would like that very much. Have you looked into it at all? According to Steve Bennett on the microblaze-linux list, David Holsgrove is working on getting microblaze support upstreamed in crosstool-ng. He's also employed by Xilinx. He would probably be the person to contact about this, and I think it would be very nice for him to be aware of musl as a development tool for microblaze (especially since they currently seem to be lacking in tools that are appropriately-sized for the sort of applications microblaze sounds most useful in). Another side project might be support for C11 Annex K. It's under discussion on the glibc list right now. I'm not sure whether they'll end up having it as an external library or built-in, but we might end up needing to go the same way for binary-compat. My leaning is an external library that's libc-agnostic, but it sounds like they want tighter libc feature integration, so we might need to have a forked (or rewritten) portable version that would work with musl even if it is external. I consider this rather low priority since nobody is using annex K (these are the ugly MS _s functions), but on the other hand it's something somebody could do on the side as a learning exercise (and useful task at the same time) without having to understand any libc internals. Rich