From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15741 invoked by alias); 22 Mar 2019 19:46:01 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 15622 invoked by uid 89); 22 Mar 2019 19:45:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy= X-HELO: mail-qk1-f193.google.com Return-Path: Subject: Re: [PATCH 0/4] Restartable Sequences support for glibc 2.30 To: Florian Weimer Cc: Mathieu Desnoyers , Carlos O'Donell , Florian Weimer , Joseph Myers , Szabolcs Nagy , libc-alpha@sourceware.org References: <20190212194253.1951-1-mathieu.desnoyers@efficios.com> <878sx6n70n.fsf@mid.deneb.enyo.de> <5a0a348e-f846-f434-3bf2-724ad7678ec0@redhat.com> <87zhpmlrvz.fsf@mid.deneb.enyo.de> From: Carlos O'Donell Message-ID: <5a722a97-f493-61a5-a46e-49daf26d75bf@redhat.com> Date: Fri, 22 Mar 2019 19:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <87zhpmlrvz.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00491.txt.bz2 On 3/22/19 1:51 PM, Florian Weimer wrote: > * Carlos O'Donell: > >> On 3/22/19 1:39 PM, Florian Weimer wrote: >>> * Mathieu Desnoyers: >>> >>>> The only point that still appears to not reach concensus is whether it's >>>> acceptable to define the RSEQ_SIG code signature for each architecture. >>>> If I missed other points that failed to reach concensus, please let me >>>> know! >>> >>> I still think the registration mechanism is very problematic and >>> should be avoided. >> >> The *entire* registration mechanism? > > The reference-counting part. It's going to be of limited use, for a > few years at most, and we'll have to carry it forward indefinitely. > I don't think it's worth the complexity. I can understand Mathieu's position here, he wants to enable all kinds of users, and wants to write libraries that use rseq today but which work with future glibc. This is a perfectly reasonable thing to want. The question we have to ask is the cost. My suggestion is as follows, tell me what you think: (a) Add a RSEQ_REGISTER_ALWAYS. The meaning of which is that the core C library does unconditional registration/unregistration for all threads, and that your application must not call rseq with flags 0 (register)/RSEQ_FLAG_UNREGISTER. (b) In a few years we remove all the ref count code and define a __rseq_lib_abi with a register_state that is set to a constant value of RSEQ_REGISTER_ALWAYS, and do nothing else. This way we have a way to backout the ref count process and just leave a public data symbol as the only part of the ABI. My idea is that we just need one more RSEQ_REGISTER_* value to indicate that libc has taken over unconditional registration. Thoughts? -- Cheers, Carlos.