* Carlos O'Donell: > On 7/13/20 11:03 PM, Mathieu Desnoyers wrote: >> Recent discussion led to a solution for extending struct rseq. This is >> an implementation of the proposed solution. >> >> Now is a good time to agree on this scheme before the release of glibc >> 2.32, just in case there are small details to fix on the user-space >> side in order to allow extending struct rseq. > > Adding extensibility to the rseq registration process would be great, > but we are out of time for the glibc 2.32 release. > > Should we revert rseq for glibc 2.32 and spend quality time discussing > the implications of an extensible design, something that Google already > says they are doing? > > We can, with a clear head, and an agreed upon extension mechanism > include rseq in glibc 2.33 (release scheduled for Feburary 1st 2021). > We release time boxed every 6 months, no deviation, so you know when > your next merge window will be. > > We have already done the hard work of fixing the nesting signal > handler issues, and glibc integration. If we revert today that will > also give time for Firefox and Chrome to adjust their sandboxes. > > Do you wish to go forward with rseq as we have it in glibc 2.32, > or do you wish to revert rseq from glibc 2.32, discuss the extension > mechanism, and put it back into glibc 2.33 with adjustments? I posted the glibc revert: <https://sourceware.org/pipermail/libc-alpha/2020-July/116368.html> I do not think we have any other choice at this point. Thanks, Florian
