[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140712051035.GA15099@brightrain.aerifal.cx>
Date: Sat, 12 Jul 2014 01:10:35 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Status towards next release (1.1.4)
I think we're pretty well on-schedule for the next release. Here's a
summary of progress so far:
- Private futex support, not committed. If we can demonstrate any
performance benefit, it can be committed, but otherwise I'm inclined
to throw it out. There's no point in adding complexity with no
evidence of benefit.
- Locale framework. Right now this is mostly just a framework and does
nothing useful.
- Byte-based C locale, not committed. As discussed previously, this is
non-essential for conforming to current standards, so I'm inclined
to omit it for now. But if there's demand for it we can consider
adding it.
- Gettext/mo file lookup core. This is not integrated with libc yet,
but tested and working.
- Openrisc (or1k) port. Stefan Kristiansson's work seems basically
complete and is in the testing phase now. I'm hoping to merge it
in the next few days.
There are several things we need to focus on now:
- The Big Bikeshed: where to find locale files? These will be somewhat
musl-specific (to the extent that no other implementation uses the
design I have in mind, though it would be easy for others to use
it), so there's no existing practice to simply adopt. The files are
not machine-specific (we'll support either endianness .mo file) so
/usr/share (or other prefix variants) is the natural base location.
- Minor coding tasks for locale. Really, this is minor. The policy of
where to find the files is a much bigger issue to work out.
- Adding non-stub public gettext API. I'd like this to happen along
with the locale work since it uses the same core operation, but it
may turn out that there are various bloated gettext features which
applications use which we don't want in the core libc itself uses
for locale, in which case we'd end up with two implementations.
- What to do with if_nameindex and getifaddrs? This issue has been
deferred for a couple releases now so I really want to solve it this
time.
The other items on the roadmap are all secondary and related to ports.
I'll be happy if we can just get or1k into this release, since it's a
nice way to draw some publicity for both projects (musl and openrisc).
But if there's time, I might do the bits refactoring (and other
port-related cleanup) in this release cycle once or1k is committed.
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.
