This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update kernel-features.h files for Linux 5.1
On 16/05/2019 08:34, Arnd Bergmann wrote:
> On Thu, May 16, 2019 at 1:15 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 16/05/2019 05:08, Arnd Bergmann wrote:
>>> On Fri, May 10, 2019 at 5:07 PM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>> On 10/05/2019 07:27, Stepan Golosunov wrote:
>>>>> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
>>>>>> Linux 5.1 adds missing syscalls to the syscall table for many Linux
>>>>>> kernel architectures. This patch updates the kernel-features.h
>>>>>> headers accordingly. I believe the statfs64 structure used by alpha
>>>>>> matches what the new kernel syscalls use, but that should be reviewed
>>>>>> carefully.
>>>>>>
>>>>>> Tested with build-many-glibcs.py.
>>>>>
>>>>> The newly added direct ipc syscalls are different from the old ones:
>>>>>
>>>>> 1. They do not accept IPC_64. This means that __IPC_64 should be set
>>>>> to zero when new syscalls are used. And new syscalls can not be used
>>>>> for compat functions like __old_semctl.
>>>>
>>>> So it seems we will need to conditionally set __IPC_64 based on kernel
>>>> version.
>>>
>>> How so? I did not expect to see any libc change here at all, unless
>>> you mean after you stop using sys_ipc().
>>
>> The idea is if user configure a minimum kernel version of v5.1,
>> sysvipc would use wire-up syscalls. So for sys_ipc the affected
>> architectures calls with required IPC_64, and for wire-up syscalls
>> IPC_64 is redefined accordingly.
>
> Ah, I see. Is there any real advantage in doing this now though?
> It seems to save a few cycles for each of those syscalls when building
> for linux-5.1+, but the cost is a significant increase in source code
> complexity.
Not really, however it gave me opportunity to clean up the sysvipc code a bit
more. I changed the __IPC_64 default value to 0x0, which simplifies a bit
new ports additions (no need to override the value); consolidates some
implementation a bit more (s390 is an outlier regarding semtimedop); and
we spot an compat issues on alpha.
I am just checking everthing is ok on a 5.1 kernel before send it to
review.