[PATCH] [powerpc] Use DIRECT_SYSVIPC_SYSCALLS

[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 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.

However, I also did not expect any existing C library to migrate from the
existing ipc() syscall to the direct calls unless it requires linux-5.1
kernels, which I guess would be 2025 at the earliest for architectures
already supported in glibc.

In particular, the decision to drop the IPC_64 flag was intended to
simplify a libc implementation that only cares about the new syscalls
by limiting the special-case architectures to alpha, arm32, microblaze,
mips, sparc and xtensa.  If you need to deal with an architecture
having different IPC_64 semantics for direct and indirect syscalls,
that clearly adds complexity instead of reducing it as I had hoped.

      Arnd