This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 07/15] Use semget syscall for Linux implementation
On Tue, Nov 1, 2016 at 1:16 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 01/11/2016 14:40, Joseph Myers wrote:
>> On Tue, 1 Nov 2016, Andreas Schwab wrote:
>>
>>> On Nov 01 2016, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
>>>
>>>> This patch add a direct call to semget syscall if it is defined by
>>>> kernel headers.
>>>
>>> That does not mean that the running kernel provides it.
>>
>> Specifically, this sort of patch series needs to be accompanied by an
>> analysis of when the relevant syscalls were added for each supported
>> architecture (and subarchitecture for cases with multiple syscall tables
>> for different ABNs). If present (in the syscall table as well as in
>> asm/unistd.h) in the minimum kernel version, OK, otherwise you need
>> appropriate __ASSUME_* conditionals (even if not present in the latest
>> kernel, it might be added in future, so you should have those conditionals
>> now to avoid breaking things when current glibc is compiled with future
>> kernel headers).
>
> Indeed, I did not consider the case of latest kernel headers. Based
> on current Linux approach and historical implementation for sysv IPC
> I think we can assume that either the kernel only supports the old
> 'ipc' syscall or all the sysvipc syscall wire-up. Do you know if we
> do require an __ASSUME for each syscall?
It wouldn't have made sense to add direct syscalls for some but not
all of the APIs that were multiplexed, so I would think one __ASSUME
is enough.
zw