This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] powerpc: Enable demuxed sysv IPC syscalls



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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]