[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <509D230F.5090404@barfooze.de>
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.
