Re: [PATCH 0/4] Restartable Sequences support for glibc 2.30

[Carlos O'Donell <codonell at redhat dot com>]

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.