Messages in this thread | | | Subject | Re: [PATCH v4 00/15] Add futex2 syscalls | From | Andrey Semashev <> | Date | Tue, 8 Jun 2021 16:41:07 +0300 |
| |
On 6/8/21 4:27 PM, Greg KH wrote: > On Tue, Jun 08, 2021 at 04:18:42PM +0300, Andrey Semashev wrote: >> On 6/8/21 3:35 PM, Greg KH wrote: >>> On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote: >>>> On 6/8/21 2:13 PM, Greg KH wrote: >>> >>>>> 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.
| |