Release plans

Release plans

[Rich Felker]

Hi all,

Most of the changes originally planned for this release cycle are
still in limbo, but as sh4rm4 mentioned on irc, there have been over
100 commits since the last release, some of them pretty significant.
So I'd like to start thinking about release.

First, a few remaining things I have in-progress that I'd like to get
in before release:

1. The new posix_spawn/popen/system:

Using clone and the close-on-exec pipe trick. I don't like leaving
in-place the current code which is dangerously broken under strace due
to bugs in strace; even if strace were fixed, buggy versions would
remain in wide use. The new code has been partially written outside
musl; it just needs to be finished and integrated.

2. Custom thread stacks:

Right now, huge TLS occupies part of the caller-provided stack space
(pthread_attr_setstack); it could even overflow the provided space.
The caller has no way to be aware of or work around this situation. I
have a new design in mind where the usual case will be to allocate new
storage for TLS, thread descriptor, and POSIX TSD even when a
caller-provided stack is used; the caller-provided stack would only be
used for TLS if the total space needed for TLS and implementation
overhead is less than 4k and less than 1/16 the caller-provided stack
size. (These numbers could be tweaked; they were chosen under the
assumption that it would be foolish to provide a stack that's only
larger than it absolutely needs to be by an absolutely or relatively
tiny margin.)

I have not started work on this change, but the final patch will be
about 15 lines. All the work is in checking that it's correct.

3. The wchar_t min/max issue:

See the forwarded email from the glibc list. I believe we have correct
definitions already in the bits headers, but it would be a lot cleaner
to drop them and use the portable definitions proposed for glibc,
which would always/automatically be right for any arch.

The remaining agenda items from the previous thread about this release
cycle are:

- strverscmp
- zoneinfo
- inet_makeaddr
- scanf %m modifier
- getifaddrs
- cpuset/affinity interfaces
- ether.h interfaces

Of those, strverscmp (based on previous discussion and drafts),
inet_makeaddr (trivial), and getifaddrs (based on legacy ioctl
interface for ipv4 and /proc/net/if_inet6 for ipv6; strace busybox
ifconfig for details) would be nice projects anyone looking to
contribute could work on without having to touch any musl internals.
Release is probably still far enough off now that work started on any
of these right away could make it into the next release.

Rich

Re: Release plans

[Strake]

On 19/01/2013, Rich Felker <dalias@aerifal.cx> wrote:
> The remaining agenda items from the previous thread about this release
> cycle are:
>
> - strverscmp
> - zoneinfo
> - inet_makeaddr
> - scanf %m modifier
> - getifaddrs
> - cpuset/affinity interfaces
> - ether.h interfaces
>
> Of those, strverscmp (based on previous discussion and drafts),
> inet_makeaddr (trivial), and getifaddrs (based on legacy ioctl
> interface for ipv4 and /proc/net/if_inet6 for ipv6; strace busybox
> ifconfig for details) would be nice projects anyone looking to
> contribute could work on without having to touch any musl internals.
> Release is probably still far enough off now that work started on any
> of these right away could make it into the next release.

What of this strverscmp: http://www.openwall.com/lists/musl/2012/12/31/17 ?

Re: Release plans

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2013-01-19 01:18:43 -0500]:
> The remaining agenda items from the previous thread about this release
> cycle are:
> 
> - strverscmp
> - zoneinfo
> - inet_makeaddr
> - scanf %m modifier
> - getifaddrs
> - cpuset/affinity interfaces
> - ether.h interfaces

there is a remaining netinet/tcp.h issue:

SOL_TCP is neither posix, nor bsd, but linux has it
and glibc has it under bsd||svid

opensolaris is supposed to be based on svr4 and it does not
have it either and win sockets use IPPROTO_TCP as well

SOL_TCP well might be a linux accident:
old kernels seem to made a distinction between the socket
level argument of setsockopt and the protocol id in the ip
header, then following bsd the two were made equal, but the
semantic distinction was kept in kernel code
(SOL_SOCKET is an exception, it collides with IPPROTO_ICMP)

http://kernelhistory.sourcentral.org/linux-0.99.14n/S/27.html#L51
vs
http://kernelhistory.sourcentral.org/linux-0.99.14u/S/27.html#L51

thus many linux networking code uses SOL_TCP as setsockopt
argument and that's what strace prints

SO* is reserved for sys/socket.h by posix so we can put SOL_*
there or use feature test macros in tcp.h

Re: Release plans

[John Spencer]

On 01/19/2013 07:18 AM, Rich Felker wrote:
> Hi all,
>
> Most of the changes originally planned for this release cycle are
> still in limbo, but as sh4rm4 mentioned on irc, there have been over
> 100 commits since the last release, some of them pretty significant.
> So I'd like to start thinking about release.
>
> First, a few remaining things I have in-progress that I'd like to get
> in before release:
[...]

i think we shouldnt try to push some features into the next release; 
apparently currently nobody is willing to look into the remaining open 
points.
imo we should just release what we have at present, so that distros have 
something current as a base to build on.
the only thing that should be added is hiltjo posthuma's fix for the 
number of days in november, which is obviously wrong at present.

Re: Release plans

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On 25 Jan 2013 01:03, "John Spencer" <maillist-musl@barfooze.de> wrote:
>
> On 01/19/2013 07:18 AM, Rich Felker wrote:
>>
>> Hi all,
>>
>> Most of the changes originally planned for this release cycle are
>> still in limbo, but as sh4rm4 mentioned on irc, there have been over
>> 100 commits since the last release, some of them pretty significant.
>> So I'd like to start thinking about release.
>>
>> First, a few remaining things I have in-progress that I'd like to get
>> in before release:
>
> [...]
>
> i think we shouldnt try to push some features into the next release;
apparently currently nobody is willing to look into the remaining open
points.
> imo we should just release what we have at present, so that distros have
something current as a base to build on.
> the only thing that should be added is hiltjo posthuma's fix for the
number of days in november, which is obviously wrong at present.
>

Willing to look but alas busy for a while. Release when release makes sense
but will be addressing issues later...

[-- Attachment #2: Type: text/html, Size: 1308 bytes --]