This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] powerpc: Enable demuxed sysv IPC syscalls
- From: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: libc-alpha at sourceware dot org, Andreas Schwab <schwab at linux-m68k dot org>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Tue, 15 Dec 2015 17:04:12 -0600
- Subject: Re: [PATCH] powerpc: Enable demuxed sysv IPC syscalls
- Authentication-results: sourceware.org; auth=none
- References: <5660A8D0 dot 5090003 at linux dot vnet dot ibm dot com> <1904883 dot fPjB3uFKBy at wuerfel> <5670840E dot 6060503 at linux dot vnet dot ibm dot com> <2556939 dot vIE1Q1Rftn at wuerfel>
On 12/15/2015 03:46 PM, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 15:20:14 Paul E. Murphy wrote:
>> Would a respin removing shmctl, semctl, and msgctl be acceptable?
>> I'd argue switching to the demuxed version is still better than going
>> through the mux. At worst this superfluously sets the IPC64 bit for
>> kernel's which assume it. Is it even possible to change the behavior
>> of these syscalls now?
> They have not yet been part of a released kernel, so I think it's still
> possible to change or remove them before 4.4 comes out. If we get the
> 4.4 release with the syscalls in place, we should not change the behavior
> any more, otherwise life gets too confusing in user space.
> Similarly, I'd argue that removing just those three syscalls but leaving
> the other ones in place would only make it harder to use them correctly
> later, because every libc that wants to use them has to not only check
> if the separate calls are available at all, but also whether the
> three *ctl calls need special treatment.
So, the bug is that some kernels check for, and clear the IPC64 bit, and
some assume it, but don't clear it? I guess that can't be checked at
Isn't that still an issue with the current implementations? I guess
IA64 gets around it by generating these syscalls code dynamically.