Thread (50 messages) 50 messages, 11 authors, 2021-06-09

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

From: Andrey Semashev <hidden>
Date: 2021-06-08 13:41:24
Also in: linux-kselftest, lkml

On 6/8/21 4:27 PM, Greg KH wrote:
On Tue, Jun 08, 2021 at 04:18:42PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 3:35 PM, Greg KH wrote:
quoted
On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote:
quoted
On 6/8/21 2:13 PM, Greg KH wrote:
quoted
quoted
So what's keeping the futex2 code from doing all that futex1 does so
that the futex1 code can be deleted internally?
I think, André will answer this, but my guess is, as stated above, this is a
lot of work and time while the intermediate version is already useful.
useful to who?  I still do not understand what users will be needing
this.  All I can tell is a single userspace program wants to use it, and
that is a fork from the real project it was based on and that the
maintainers have no plan to merge it back.

So who does need/want this?
I mentioned C++ std::atomic and Boost.Atomic before. Those need variable
sized futexes.
And has anyone converted them to use this new api to see if it works
well or not?

As was pointed out to me numerous times when I tried to propose
readfile(), you need a real user that can show and prove it is needed
before we can take new syscalls, especially complex beasts like this
one.
André has mentioned that he tested the patch set with patched Wine and 
glibc.

I didn't patch Boost.Atomic or std::atomic, but it doesn't look to be 
problematic. The only difference it would make there is to enable 
futex2-based implementation for multiple atomic sizes and set up flags 
to indicate the futex size, instead of only enabling futex-based 
implementation for 32-bit atomics.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help