[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121108222452.GX20323@brightrain.aerifal.cx>
Date: Thu, 8 Nov 2012 17:24:52 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: roadmap for 0.9.8 ?
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 <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.
> 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
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.
