glibc 2.32 release strategy for ABI changes.

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list
In a short moment I will declare the ABI frozen for changes, and only
changes authorized by the release manager will be allowed. Bug fixes
will still be allowed.

As release manager I want to carry out the following steps as part
of the coordinated ABI changes for the glibc 2.32 release:

(1) I want to see Adhemerval's signum-{generic,arch}.h series pushed
    after a final review. I think this is ready and adds APIs for
    the data we used to export and deprecates the other interfaces.

(2) I want to see HJ's <sys/platform/x86.h> series reviewed and
    accepted and pushed or deferred for further discussion.

    - HJ, Florian, What's the status on this?

(3) I want to see the __libc_single_thread patches pushed. These
    have been extensively reviewed and are ready for use.

(4) I want to see the rseq changes pushed. These have been
    extensively reviewed, but testing has shown a problem with
    the audit module framework, but a straight forward fix is
    available for that (raise TLS_TCB_ALIGN as required) [1].

(5) I want to review and get Adhemerval's 64-bit time_t fixes
    pushed.

(6) I want to see the ARC port pushed *after* (5) and after
    review says they are ready.

    - Vineet, If we get all of (5), is anything else needed?

(7) I want to see the RISC-V 32-bit port pushed *after* (5)
    and after review says they are ready.

    - Alistair, If we get all of (5), is there anything else needed?

(8) I want to see the SunRPC deprecation pushed *after* (6)
    and after review says they are ready. We want to do it in
    this order to prove that the SunRPC deprecation correctly
    cleans up a port, the ARC port, with a 2.32 baseline and
    removes all trace of the old baseline compat symbols.

I want to complete all of this by July 10th (next week).

I do not want to add anything else to this already large list.

The non-ABI fixes can keep going in and I'm particularly keen
to see these fixes:

(a) AArch64 BTI and PAC-RET.

(b) Szabolcs's TLS reservation fixes.
    - Internal ABI changes are OK e.g. GLIBC_PRIVATE.

(c) Chung-Lin Tang's DSO sorting fixes.

(d) DJ's NSS nsswitch.conf reloading changes.

(e) Regression fix for en_US date.

(f) x86: Add thresholds for "rep movsb/stosb" to tunables

I want machine maintainers to test from July 13 to July 30th.

I want to cut the branch August 3rd.

Please review the above details. If anything seems out of place
please call it out. If we are missing dependencies or if you think
something won't make the cut, please say so.

As a reminder glibc runs a time boxed release. I will cut features
and revert code to make the August 3rd release.

--
Cheers,
Carlos.

[1] https://sourceware.org/pipermail/libc-alpha/2020-July/115758.html

Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list


On 03/07/2020 18:49, Carlos O'Donell wrote:
>
> (5) I want to review and get Adhemerval's 64-bit time_t fixes
>     pushed.

This is not strictly an ABI change, it should not change the SysVIPC
semantic for current 32-bit architecture with 32-bit time_t. It is
mainly to add support for 32-bit architecture with 64-bit time_t
(which would export symbol with names similar to 64-bit architectures).
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list
Hi Carlos,

On 7/3/20 2:49 PM, Carlos O'Donell via Libc-alpha wrote:

> In a short moment I will declare the ABI frozen for changes, and only
> changes authorized by the release manager will be allowed. Bug fixes
> will still be allowed.
>
> As release manager I want to carry out the following steps as part
> of the coordinated ABI changes for the glibc 2.32 release:
>
> (1) I want to see Adhemerval's signum-{generic,arch}.h series pushed
>     after a final review. I think this is ready and adds APIs for
>     the data we used to export and deprecates the other interfaces.
>
> (2) I want to see HJ's <sys/platform/x86.h> series reviewed and
>     accepted and pushed or deferred for further discussion.
>
>     - HJ, Florian, What's the status on this?
>
> (3) I want to see the __libc_single_thread patches pushed. These
>     have been extensively reviewed and are ready for use.
>
> (4) I want to see the rseq changes pushed. These have been
>     extensively reviewed, but testing has shown a problem with
>     the audit module framework, but a straight forward fix is
>     available for that (raise TLS_TCB_ALIGN as required) [1].
>
> (5) I want to review and get Adhemerval's 64-bit time_t fixes
>     pushed.
>
> (6) I want to see the ARC port pushed *after* (5) and after
>     review says they are ready.
>
>     - Vineet, If we get all of (5), is anything else needed?

Nope, I only need #5 and ARC review is also progressing well (big thx to Arnaldo
for promsing to do that by end of this week and keeping it).

Much thx for following up.

-Vineet
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list
On 7/3/20 8:24 PM, Vineet Gupta via Libc-alpha wrote:
> Nope, I only need #5 and ARC review is also progressing well (big thx to Arnaldo
> for promsing to do that by end of this week and keeping it).

/me slaps myself. Big Thx to Adhemerval

-Vineet
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list
On Fri, Jul 3, 2020 at 2:49 PM Carlos O'Donell <[hidden email]> wrote:

>
> In a short moment I will declare the ABI frozen for changes, and only
> changes authorized by the release manager will be allowed. Bug fixes
> will still be allowed.
>
> As release manager I want to carry out the following steps as part
> of the coordinated ABI changes for the glibc 2.32 release:
>
> (1) I want to see Adhemerval's signum-{generic,arch}.h series pushed
>     after a final review. I think this is ready and adds APIs for
>     the data we used to export and deprecates the other interfaces.
>
> (2) I want to see HJ's <sys/platform/x86.h> series reviewed and
>     accepted and pushed or deferred for further discussion.
>
>     - HJ, Florian, What's the status on this?

I sent out the latest patch to address Florian's concerns:

https://sourceware.org/pipermail/libc-alpha/2020-June/115546.html

I am waiting for feedback.

> (3) I want to see the __libc_single_thread patches pushed. These
>     have been extensively reviewed and are ready for use.
>
> (4) I want to see the rseq changes pushed. These have been
>     extensively reviewed, but testing has shown a problem with
>     the audit module framework, but a straight forward fix is
>     available for that (raise TLS_TCB_ALIGN as required) [1].
>
> (5) I want to review and get Adhemerval's 64-bit time_t fixes
>     pushed.
>
> (6) I want to see the ARC port pushed *after* (5) and after
>     review says they are ready.
>
>     - Vineet, If we get all of (5), is anything else needed?
>
> (7) I want to see the RISC-V 32-bit port pushed *after* (5)
>     and after review says they are ready.
>
>     - Alistair, If we get all of (5), is there anything else needed?
>
> (8) I want to see the SunRPC deprecation pushed *after* (6)
>     and after review says they are ready. We want to do it in
>     this order to prove that the SunRPC deprecation correctly
>     cleans up a port, the ARC port, with a 2.32 baseline and
>     removes all trace of the old baseline compat symbols.
>
> I want to complete all of this by July 10th (next week).
>
> I do not want to add anything else to this already large list.
>
> The non-ABI fixes can keep going in and I'm particularly keen
> to see these fixes:
>
> (a) AArch64 BTI and PAC-RET.
>
> (b) Szabolcs's TLS reservation fixes.
>     - Internal ABI changes are OK e.g. GLIBC_PRIVATE.
>
> (c) Chung-Lin Tang's DSO sorting fixes.
>
> (d) DJ's NSS nsswitch.conf reloading changes.
>
> (e) Regression fix for en_US date.
>
> (f) x86: Add thresholds for "rep movsb/stosb" to tunables
>
> I want machine maintainers to test from July 13 to July 30th.
>
> I want to cut the branch August 3rd.
>
> Please review the above details. If anything seems out of place
> please call it out. If we are missing dependencies or if you think
> something won't make the cut, please say so.
>
> As a reminder glibc runs a time boxed release. I will cut features
> and revert code to make the August 3rd release.
>
> --
> Cheers,
> Carlos.
>
> [1] https://sourceware.org/pipermail/libc-alpha/2020-July/115758.html
>


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Joseph Myers
In reply to this post by Sourceware - libc-alpha mailing list
On Fri, 3 Jul 2020, Carlos O'Donell via Libc-alpha wrote:

> The non-ABI fixes can keep going in and I'm particularly keen
> to see these fixes:

Please note my patch
<https://sourceware.org/pipermail/libc-alpha/2020-July/115673.html>
awaiting comments on whether it's appropriate at this development stage
(we don't generally treat that sort of change as an ABI change, but
sometimes we do).

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list
On 7/6/20 11:36 AM, Joseph Myers wrote:

> On Fri, 3 Jul 2020, Carlos O'Donell via Libc-alpha wrote:
>
>> The non-ABI fixes can keep going in and I'm particularly keen
>> to see these fixes:
>
> Please note my patch
> <https://sourceware.org/pipermail/libc-alpha/2020-July/115673.html>
> awaiting comments on whether it's appropriate at this development stage
> (we don't generally treat that sort of change as an ABI change, but
> sometimes we do).

Reviewed and accepted. Thanks for raising this here.

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list
Status update time:

On 7/3/20 5:49 PM, Carlos O'Donell wrote:
> (1) I want to see Adhemerval's signum-{generic,arch}.h series pushed
>     after a final review. I think this is ready and adds APIs for
>     the data we used to export and deprecates the other interfaces.

This is done and pushed.
 
> (2) I want to see HJ's <sys/platform/x86.h> series reviewed and
>     accepted and pushed or deferred for further discussion.
>
>     - HJ, Florian, What's the status on this?

This is under review.

> (3) I want to see the __libc_single_thread patches pushed. These
>     have been extensively reviewed and are ready for use.

This is done and pushed.

> (4) I want to see the rseq changes pushed. These have been
>     extensively reviewed, but testing has shown a problem with
>     the audit module framework, but a straight forward fix is
>     available for that (raise TLS_TCB_ALIGN as required) [1].

This is done and pushed.

Along with:
- elf: Do not signal LA_ACT_CONSISTENT for an empty namespace [BZ #26076]
  (to fix subsequent surplus TLS changes)

> (5) I want to review and get Adhemerval's 64-bit time_t fixes
>     pushed.

This is now reviewed.

This unblocks (6) and (7). Full steam ahead.

> (6) I want to see the ARC port pushed *after* (5) and after
>     review says they are ready.
>
>     - Vineet, If we get all of (5), is anything else needed?

What is our status on the ARC port?

Do we need additional review?

> (7) I want to see the RISC-V 32-bit port pushed *after* (5)
>     and after review says they are ready.
>
>     - Alistair, If we get all of (5), is there anything else needed?

What is our status on the RISC-V 32-bit port?

Do we need additional review?

> (8) I want to see the SunRPC deprecation pushed *after* (6)
>     and after review says they are ready. We want to do it in
>     this order to prove that the SunRPC deprecation correctly
>     cleans up a port, the ARC port, with a 2.32 baseline and
>     removes all trace of the old baseline compat symbols.

I have ack'd or reviewed:
- sunrpc: Remove hidden aliases for global data symbols [BZ #26210]
- sunrpc symbol cleanups

I don't think I've seen a final v6 of the deprecation patches here
https://sourceware.org/pipermail/libc-alpha/2020-June/115574.html
that is a non-RFC.

We should move on that so we can clean this up for ARC and RISC-V 32-bit.

> I want to complete all of this by July 10th (next week).
>
> I do not want to add anything else to this already large list.
>
> The non-ABI fixes can keep going in and I'm particularly keen
> to see these fixes:
>
> (a) AArch64 BTI and PAC-RET.

Status?
 
> (b) Szabolcs's TLS reservation fixes.
>     - Internal ABI changes are OK e.g. GLIBC_PRIVATE.

Reviewed. Needs some fixing up after rseq changes. No semantic problems,
just needing extra TLS surplus to satisfy 8 module tests e.g. tst-auditmany.
 
> (c) Chung-Lin Tang's DSO sorting fixes.

Reviewed and waiting on new version to review.
 
> (d) DJ's NSS nsswitch.conf reloading changes.

Next up for me to review.

> (e) Regression fix for en_US date.

Next up for me to post.
 
> (f) x86: Add thresholds for "rep movsb/stosb" to tunables

Reviewed and pushed.

> I want machine maintainers to test from July 13 to July 30th.
>
> I want to cut the branch August 3rd.
>
> Please review the above details. If anything seems out of place
> please call it out. If we are missing dependencies or if you think
> something won't make the cut, please say so.
>
> As a reminder glibc runs a time boxed release. I will cut features
> and revert code to make the August 3rd release.

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list
On Tue, Jul 7, 2020 at 2:45 PM Carlos O'Donell <[hidden email]> wrote:

>
> Status update time:
>
> On 7/3/20 5:49 PM, Carlos O'Donell wrote:
> > (1) I want to see Adhemerval's signum-{generic,arch}.h series pushed
> >     after a final review. I think this is ready and adds APIs for
> >     the data we used to export and deprecates the other interfaces.
>
> This is done and pushed.
>
> > (2) I want to see HJ's <sys/platform/x86.h> series reviewed and
> >     accepted and pushed or deferred for further discussion.
> >
> >     - HJ, Florian, What's the status on this?
>
> This is under review.
>
> > (3) I want to see the __libc_single_thread patches pushed. These
> >     have been extensively reviewed and are ready for use.
>
> This is done and pushed.
>
> > (4) I want to see the rseq changes pushed. These have been
> >     extensively reviewed, but testing has shown a problem with
> >     the audit module framework, but a straight forward fix is
> >     available for that (raise TLS_TCB_ALIGN as required) [1].
>
> This is done and pushed.
>
> Along with:
> - elf: Do not signal LA_ACT_CONSISTENT for an empty namespace [BZ #26076]
>   (to fix subsequent surplus TLS changes)
>
> > (5) I want to review and get Adhemerval's 64-bit time_t fixes
> >     pushed.
>
> This is now reviewed.
>
> This unblocks (6) and (7). Full steam ahead.
>
> > (6) I want to see the ARC port pushed *after* (5) and after
> >     review says they are ready.
> >
> >     - Vineet, If we get all of (5), is anything else needed?
>
> What is our status on the ARC port?
>
> Do we need additional review?
>
> > (7) I want to see the RISC-V 32-bit port pushed *after* (5)
> >     and after review says they are ready.
> >
> >     - Alistair, If we get all of (5), is there anything else needed?
>
> What is our status on the RISC-V 32-bit port?

Patches are on the list and waiting for review.

>
> Do we need additional review?

Yes!

Alistair
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Sourceware - libc-alpha mailing list
In reply to this post by Sourceware - libc-alpha mailing list
Hi Carlos,

On 7/7/20 2:44 PM, Carlos O'Donell via Libc-alpha wrote:
>> (6) I want to see the ARC port pushed *after* (5) and after
>>     review says they are ready.
>>
>>     - Vineet, If we get all of (5), is anything else needed?
> What is our status on the ARC port?
>
> Do we need additional review?

I last patch needs a formal "Reviewed-by". I've sent a respin earlier today.

Thx,
-Vineet
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Szabolcs Nagy-2
In reply to this post by Sourceware - libc-alpha mailing list
The 07/07/2020 17:44, Carlos O'Donell wrote:
> > (a) AArch64 BTI and PAC-RET.
>
> Status?
>  
> > (b) Szabolcs's TLS reservation fixes.
> >     - Internal ABI changes are OK e.g. GLIBC_PRIVATE.
>
> Reviewed. Needs some fixing up after rseq changes. No semantic problems,
> just needing extra TLS surplus to satisfy 8 module tests e.g. tst-auditmany.

i'm about to post updated version of (a) and (b).

bti and pac-ret were reviewed by Adhemerval and i
think the updated version will be ready for commit.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Szabolcs Nagy-2
The 07/08/2020 10:33, Szabolcs Nagy wrote:

> The 07/07/2020 17:44, Carlos O'Donell wrote:
> > > (a) AArch64 BTI and PAC-RET.
> >
> > Status?
> >  
> > > (b) Szabolcs's TLS reservation fixes.
> > >     - Internal ABI changes are OK e.g. GLIBC_PRIVATE.
> >
> > Reviewed. Needs some fixing up after rseq changes. No semantic problems,
> > just needing extra TLS surplus to satisfy 8 module tests e.g. tst-auditmany.
>
> i'm about to post updated version of (a) and (b).
>
> bti and pac-ret were reviewed by Adhemerval and i
> think the updated version will be ready for commit.

now both series are posted, i need review on
(a)/1 (abi-note.S rewrite),
(a)/14 (NEWS entry for BTI)
(b)/2 (accounting tls for audit modules)

Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Szabolcs Nagy-2
The 07/08/2020 13:21, Szabolcs Nagy wrote:

> The 07/08/2020 10:33, Szabolcs Nagy wrote:
> > The 07/07/2020 17:44, Carlos O'Donell wrote:
> > > > (a) AArch64 BTI and PAC-RET.
> > >
> > > Status?
> > >  
> > > > (b) Szabolcs's TLS reservation fixes.
> > > >     - Internal ABI changes are OK e.g. GLIBC_PRIVATE.
> > >
> > > Reviewed. Needs some fixing up after rseq changes. No semantic problems,
> > > just needing extra TLS surplus to satisfy 8 module tests e.g. tst-auditmany.
> >
> > i'm about to post updated version of (a) and (b).
> >
> > bti and pac-ret were reviewed by Adhemerval and i
> > think the updated version will be ready for commit.
>
> now both series are posted, i need review on
> (a)/1 (abi-note.S rewrite),
> (a)/14 (NEWS entry for BTI)

BTI and PAC-RET is now committed.

> (b)/2 (accounting tls for audit modules)

i need a review of the tunables.texi changes
in the audit module accounting patch.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.32 release strategy for ABI changes.

Szabolcs Nagy-2
The 07/08/2020 15:08, Szabolcs Nagy wrote:

> The 07/08/2020 13:21, Szabolcs Nagy wrote:
> > The 07/08/2020 10:33, Szabolcs Nagy wrote:
> > > The 07/07/2020 17:44, Carlos O'Donell wrote:
> > > > > (a) AArch64 BTI and PAC-RET.
> > > >
> > > > Status?
> > > >  
> > > > > (b) Szabolcs's TLS reservation fixes.
> > > > >     - Internal ABI changes are OK e.g. GLIBC_PRIVATE.
> > > >
> > > > Reviewed. Needs some fixing up after rseq changes. No semantic problems,
> > > > just needing extra TLS surplus to satisfy 8 module tests e.g. tst-auditmany.
> > >
> > > i'm about to post updated version of (a) and (b).
> > >
> > > bti and pac-ret were reviewed by Adhemerval and i
> > > think the updated version will be ready for commit.
> >
> > now both series are posted, i need review on
> > (a)/1 (abi-note.S rewrite),
> > (a)/14 (NEWS entry for BTI)
>
> BTI and PAC-RET is now committed.
>
> > (b)/2 (accounting tls for audit modules)
>
> i need a review of the tunables.texi changes
> in the audit module accounting patch.

now all patches are committed.