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

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

From: Greg KH <gregkh@linuxfoundation.org>
Date: 2021-06-08 12:35:19
Also in: linux-kselftest, lkml

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.
quoted
Best of all would be if internally your "futex2" code would replace the
"futex1" code so that there is no two different code bases.  That would
be the only sane way forward, having 2 code bases to work with is just
insane.
Yes, implementing futex1 in terms of futex2 internally is a possible way
forward. Though I'm not sure it is reasonable to require that to be done in
the initial futex2 submission. This requires all of the futex1 functionality
to implemented in futex2 from the start, which I think is too much to ask.
Even with some futex1 features missing, futex2 would be already very much
useful to users, and it is easier to implement the missing bits
incrementally over time.
Then do it the other way around, as Peter points out.
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?

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help