Remaining roadmap targets for 1.1.3

Remaining roadmap targets for 1.1.3

[Rich Felker]

Here are the not-yet-done primary targets from the roadmap:

- Resolver: IDN and result sorting.
- Overhaul of if_nameindex and getifaddrs.
- Merging fmtmsg. (I have reviewed it now though.)
- Merging ports. (Probably not going to happen in this cycle.)

And secondary ones:

- Promoting x32 and sh from experimental.
- Deduplicating header bits.
- Private futex.

And old items from the post-1.1.1 plans thread:
- max_align_t
- __xmknod and __sysv_signal patch (ABI compat)
- sysconf(_SC_LINE_MAX) issue
- errc-family functions
- error.h
- reallocarray
- explicit_bzero

If we want to keep with the time-based release cycle aiming for mid to
late June, I don't think we can do all of the above in time for 1.1.3.

In terms of importance, the things I most want to get done are the
resolver/network items. IDN is probably the least important among
them, and could easily be pushed back. This might make sense anyway
since the next release cycle is supposed to be focused on locale
related improvements.

I really want to do the bits header deduplication but I ran into some
snags. I might write up a separate email on this, or just discuss it
on IRC more.

Most other items will probably have to wait, but fmtmsg could still
make it in if Isaac follows up on my review between now and release.

Anything else I should look at including?

Rich

Re: Remaining roadmap targets for 1.1.3

[Isaac Dunham]

On Fri, Jun 20, 2014 at 12:40:32AM -0400, Rich Felker wrote:
> Here are the not-yet-done primary targets from the roadmap:
> 
> - Resolver: IDN and result sorting.
> - Overhaul of if_nameindex and getifaddrs.
> - Merging fmtmsg. (I have reviewed it now though.)
v3 has been sent.

> - Merging ports. (Probably not going to happen in this cycle.)
Which ones? Aarch64, I'm guessing?

> And secondary ones:
> 
> - Promoting x32 and sh from experimental.
> - Deduplicating header bits.
> - Private futex.
> 
> And old items from the post-1.1.1 plans thread:
> - max_align_t
> - __xmknod and __sysv_signal patch (ABI compat)
> - sysconf(_SC_LINE_MAX) issue
> - errc-family functions
See [RFC] [v2] Implement errc/warnc family of functions
from June 13.
(summary: it may not be needed after all, but here's a patch that
makes vwarn() call vwarnc(). )
> - error.h
> - reallocarray
> - explicit_bzero
I lost track of whether those would be included or not...

Thanks,
Isaac Dunham

PS: When I send a revision of a patch, should I send it to the same
thread or start a new one?

Re: Remaining roadmap targets for 1.1.3

[Rich Felker]

On Fri, Jun 20, 2014 at 07:59:57AM -0700, Isaac Dunham wrote:
> On Fri, Jun 20, 2014 at 12:40:32AM -0400, Rich Felker wrote:
> > Here are the not-yet-done primary targets from the roadmap:
> > 
> > - Resolver: IDN and result sorting.
> > - Overhaul of if_nameindex and getifaddrs.
> > - Merging fmtmsg. (I have reviewed it now though.)
> v3 has been sent.

Yes, I'm going to look at it now. Thanks!

> > - Merging ports. (Probably not going to happen in this cycle.)
> Which ones? Aarch64, I'm guessing?

Actually or1k (openrisc) was the one I had more hope for getting in
this release cycle, but yes also aarch64. The latter seems rather
stalled and we have several people who've worked on a port but each
left it in a partial state. Not sure what's the best path forward to
finish it.

> > And old items from the post-1.1.1 plans thread:
> > - max_align_t
> > - __xmknod and __sysv_signal patch (ABI compat)
> > - sysconf(_SC_LINE_MAX) issue
> > - errc-family functions
> See [RFC] [v2] Implement errc/warnc family of functions
> from June 13.
> (summary: it may not be needed after all, but here's a patch that
> makes vwarn() call vwarnc(). )

Yes, I'm fine with omitting these if nobody objects.

> > - error.h
> > - reallocarray
> > - explicit_bzero
> I lost track of whether those would be included or not...

Part of the agenda item is determining if they should be included. The
proposal for reallocarray seems to have been accepted by glibc, so
it's a likely candidate for inclusion. explicit_bzero seems like a bad
API (resurrecting the deprecasted bzero vs memset, poorly chosen name,
...) but I guess time will tell. As for error.h, I'm not sufficiently
knowledgable about it to have an opinion yet.

> PS: When I send a revision of a patch, should I send it to the same
> thread or start a new one?

Either is fine, but either way it's nice to put [PATCH v2] or similar
in the subject (really anything to catch my attention that there's a
new patch attached).

Rich

Re: Remaining roadmap targets for 1.1.3

[Rich Felker]

On Fri, Jun 20, 2014 at 12:40:32AM -0400, Rich Felker wrote:
> Here are the not-yet-done primary targets from the roadmap:
> 
> - Resolver: IDN and result sorting.

Result sorting is done, modulo any potential bugs. Please test if you
can. In typical usage, IPv6 results (whether from /etc/hosts or DNS)
should be showing up last if you have an IPv4-only setup or if the
only IPv6 route is over 6to4, and first if you have a real IPv6 setup.
For results that are a mix of link-local or other differently-scoped
addresses the sorting is more complex. Testing with fancy IPv6 setups
would be very helpful.

> - Overhaul of if_nameindex and getifaddrs.

Still pending.

> - Merging fmtmsg. (I have reviewed it now though.)

Done.

> - Merging ports. (Probably not going to happen in this cycle.)

Indeed. or1k is mostly done, but probably not enough to think about a
merge yet, especially since it needs refitting for the reloc.h
changes. No idea on the status of aarch64.

> And secondary ones:
> 
> - Promoting x32 and sh from experimental.
> - Deduplicating header bits.
> - Private futex.

Let's punt on all these.

> And old items from the post-1.1.1 plans thread:
> - max_align_t

Still not sure what's best. Perhaps we should define max_align_t to
have alignment of MIN(8, alignof(long long), alignof(double),
alignof(long double)) or similar since that seems to be effectively
what GCC is doing. However I don't see any way to give the _type_ such
alignment without depending on GNU C. Per C11 I don't think _Alignas
is valid on struct/union members but I seem to remember hearing that
the committee is considering this a defect. Anyway, the whole topic is
probably still too complex to deal with between now and release.

> - __xmknod and __sysv_signal patch (ABI compat)

I just looked up the confusing mess with __xmknod taking a dev_t *
rather than dev_t, so I think I can knock this one off the list
between now and release.

> - sysconf(_SC_LINE_MAX) issue
> - errc-family functions
> - error.h
> - reallocarray
> - explicit_bzero

I think all of these should be deferred for now.

Rich

Re: Remaining roadmap targets for 1.1.3

[Jens Gustedt]

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

Hi,

Am Samstag, den 21.06.2014, 23:37 -0400 schrieb Rich Felker:
> On Fri, Jun 20, 2014 at 12:40:32AM -0400, Rich Felker wrote:
> > And old items from the post-1.1.1 plans thread:
> > - max_align_t
> 
> Still not sure what's best. Perhaps we should define max_align_t to
> have alignment of MIN(8, alignof(long long), alignof(double),
> alignof(long double)) or similar since that seems to be effectively
> what GCC is doing. However I don't see any way to give the _type_ such
> alignment without depending on GNU C. Per C11 I don't think _Alignas
> is valid on struct/union members but I seem to remember hearing that
> the committee is considering this a defect.

Yes, there are two DR about alignment issues

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_444.htm
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_445.htm

in particular DR 444 is about applying _Alignas to members. There seem
to be consensus to make this possible, a solution is in the works.

Jens


-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]