Re: [PATCH] [powerpc] Use DIRECT_SYSVIPC_SYSCALLS

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 11/10/2019 06:19, Florian Weimer wrote:
> * Arnd Bergmann:
> 
>> On Thu, Oct 10, 2019 at 6:18 PM Paul Clarke <pc@us.ibm.com> wrote:
>>> On 10/10/19 1:07 AM, Florian Weimer wrote:
>>
>>>> I think the best way forward here is to fix the kernel to provide the
>>>> semop system call on POWER, and change __ASSUME_DIRECT_SYSVIPC_SYSCALLS
>>>> so that it requires that kernel version as the minimum on POWER.
>>>
>>> The same historical thread referenced above started with a patch [2] from 2015 to realize the same effect. In that thread, Michael Ellerman and Arnd Bergman discuss reverting the original support patches from Linux 4.4, which don't appear again, it seems, until Linux 5.0.  But, it seems that "semop" was not included in that patchset (Linux kernel commit 0d6040d468173).  Is that expected, Arnd?
>>
>> Yes, that was intentional: as semop is a trivial subset of
>> semtimedop/semtimedop_time64,
> 
> It's not so trivial anymore because you need to pick the right syscall
> to replace it. 8-/
> 
>> it seemed pointless to add both, as I wrote in the changeset text then:
>>
>>    "I'm not adding the new semtimedop() or semop() on 32-bit architectures,
>>     those will get implemented using the new semtimedop_time64() version
>>     that gets added along with the other time64 calls.
>>     Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop()."
>>
>> My expectation then was that glibc would make its semop() interface a
>> wrapper around its own semtimedop() interface, which needs to be
>> implemented anyway. That implementation would then be shared across
>> all architectures.
> 
> Thanks for this background.  This suggests to me that with
> __ASSUME_DIRECT_SYSVIPC_SYSCALLS, the generic implementation should use
> semtimedop or semtimedop_time64, and that in the interim, Paul's patch
> (with a commont explaining why) is safe with regards future evolution of
> the kernel.
I think it would simpler then to just refactor semop to call semtimedop,
so the wire-up support only will need to touch semtimedop code.  In any
case I will send a updated version on my previous proposal (which is
similar of what Paul sent, but with wire-up support for affected
architectures).