Re: [PATCH v4 00/15] Add futex2 syscalls

On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:

On 6/8/21 2:13 PM, Greg KH wrote:

quoted

On Tue, Jun 08, 2021 at 02:03:50PM +0300, Andrey Semashev wrote:

quoted

On 6/8/21 4:25 AM, Nicholas Piggin wrote:

quoted

Are shared pthread mutexes using existing pthread APIs that are today
implemented okay with futex1 system call a good reason to constrain
futex2 I wonder? Or do we have an opportunity to make a bigger change
to the API so it suffers less from non deterministic latency (for
example)?

If futex2 is not able to cover futex1 use cases then it cannot be viewed as
a replacement. In the long term this means futex1 cannot be deprecated and
has to be maintained. My impression was that futex1 was basically
unmaintainable(*) and futex2 was an evolution of futex1 so that users of
futex1 could migrate relatively easily and futex1 eventually removed. Maybe
my impression was wrong, but I would like to see futex2 as a replacement and
extension of futex1, so the latter can be deprecated at some point.

You can never delete a kernel system call, so even if you "deprecate"
it, it still needs to be supported for forever.

If I'm not mistaken, some syscalls were dropped from kernel in the past,
after it was established they are no longer used. So it is not impossible,
though might be more difficult specifically with futex.

Those syscalls were all "compatible with other obsolete operating
system" syscalls from what I remember.  You can still run binaries
built in 1995 just fine on your system today (I have a few around here
somewhere...)

Thinking that you can drop futex() in the next 10+ years is very wishful
thinking given just how slow userspace applications are ever updated,
sorry.

greg k-h