This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: Enable demuxed sysv IPC syscalls
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 3 Dec 2015 21:37:58 -0200
- 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> <5660AFE5 dot 1060001 at linaro dot org> <alpine dot DEB dot 2 dot 10 dot 1512032221460 dot 1888 at digraph dot polyomino dot org dot uk> <5660C8B9 dot 1020305 at linaro dot org> <alpine dot DEB dot 2 dot 10 dot 1512032257380 dot 1888 at digraph dot polyomino dot org dot uk>
On 03-12-2015 21:00, Joseph Myers wrote:
> On Thu, 3 Dec 2015, Adhemerval Zanella wrote:
>
>> On 03-12-2015 20:22, Joseph Myers wrote:
>>> On Thu, 3 Dec 2015, Adhemerval Zanella wrote:
>>>
>>>> My inclination would to avoid the __ASSUME_XXX macros definition and just
>>>> check if the current kernel header defines of not __NR_msgctl and use it
>>>> as the condition to enable the wire-up syscall.
>>>
>>> I'm not clear exactly what you're suggesting. If you check like that
>>> (whether the kernel headers, possibly for a newer kernel than the minimum
>>> supported by that glibc build, define a syscall number) then you need a
>>> run-time fallback if the new syscall fails with ENOSYS.
>>
>> But building with a newer kernel header will bind the libc.so to the
>> specific version, isn't? I am assuming ENOSYS will be retuned only when
>
> No. You should almost always build with the newest kernel headers
> available so that glibc contains the support for new syscalls etc. (which
> may or may not work at runtime depending on the kernel headers version
> used then). Each of (kernel headers version, kernel version used at
> runtime) must be at least (minimum kernel version specified with
> --enable-kernel), but there is no ordering requirement between (kernel
> headers version) and (kernel version used at runtime). Use of new
> syscalls to implement functionality previously supported on older kernels
> needs runtime fallback unless restricted with --enable-kernel (for
> completely new functionality, we can judge case-by-case how useful
> fallbacks are).
>
I just realized after sent the kernel of the case where you have
newer kernels, but enable the older kernel support explicitly.
I withdraw my suggestion.