[v2,1/1] powerpc: Individual System V IPC system calls

[Sam Bobroff]

On Tue, Oct 13, 2015 at 08:38:42PM +1100, Michael Ellerman wrote:
> On Tue, 2015-13-10 at 01:49:28 UTC, Sam bobroff wrote:
> > This patch provides individual system call numbers for the following
> > System V IPC system calls, on PowerPC, so that they do not need to be
> > multiplexed:
> > * semop, semget, semctl, semtimedop
> > * msgsnd, msgrcv, msgget, msgctl
> > * shmat, shmdt, shmget, shmctl
> 
> You tested this right? :)  Tell me about it.

Why yes I did:

I have written a (fairly) trivial test program that calls each function in a
way that doesn't fail (but that doesn't necessarily attempt to exercise the
full functionality of it; my intent was primarily to validate the parameter
passing part as that is where most of the code change is (on the glibc side)).

I patched a local copy of glibc with the new kernel header and various tweaks
to correctly format the parameter lists for the new calls (there is actually
quite a lot of code in glibc around the IPC calls due to various compatibility
issues). I could then build a full tool chain that supported the new calls.

(This was a lot more extensive than the kernel patch but should be fairly close
to what needs to go into glibc.)

I used that tool chain to build a complete host system (using buildroot). Then
I could run the following tests:

* glibc: stock
  Host kernel: stock
  Result: success
  Notes: As expected, base case.

* glibc: stock
  Host kernel: patched
  Result: success
  Notes: As expected, the old ipc() call still exists in the patched host.

* glibc: patched
  Host kernel: stock
  Result: failure
  Notes: As expected, the test was run with a glibc that requires a patched
  kernel on an unpatched one so the syscalls are unknown.

* glibc: patched
  Host kernel: patched
  Result: success
  Notes: As expected. (Also, a bit of debug in glibc shows the new system call
  paths being followed.)

(I also re-ran the tests both for little-endian and big-endian hosts.)

It would obviously be good to have someone else test this, but I can't see a
way to make it easy to do. They would presumably have to go through all of the
above, which seems too much to ask given how trivial the kernel side of the
patch is. Still, it bothers me a bit so if there is any way please let me know.
(I thought about writing some assembly to directly test the syscall numbers but
all it would do is verify that the numbers are valid, which really isn't much
of a test.)

> Also we could make these available to SPU programs, but I don't think there's
> any point, no one's going to do a libc update for that.
> 
> cheers

Cheers,
Sam.