This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: AArch64 ILP32 abi in glibc
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: nd at arm dot com, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Catalin Marinas <catalin dot marinas at arm dot com>, Carlos O'Donell <carlos at redhat dot com>, Steve Ellcey <sellcey at caviumnetworks dot com>, Andrew Pinski <pinskia at gmail dot com>
- Date: Thu, 29 Jun 2017 19:56:34 +0100
- Subject: Re: AArch64 ILP32 abi in glibc
- Authentication-results: sourceware.org; auth=none
- Authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <59553555.3010004@arm.com> <b3126c58-f956-44ee-7540-f7d8ab71acb7@linaro.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 29/06/17 18:47, Adhemerval Zanella wrote:
> On 29/06/2017 14:13, Szabolcs Nagy wrote:
>> The patches to support ILP32 in the Linux kernel are not going
>> into mainline, so the ILP32 port cannot be accepted into glibc
>> master yet, see
>>
>> https://lkml.org/lkml/2017/6/29/557
>>
>> On the glibc side the plan is to create an ILP32 branch once the
>> known glibc and kernel side issues are resolved. This way we have
>> a canonical upstream branch for all ILP32 activity and we would
>> like downstream consumers to use this branch. Contributions to
>> this branch should go through the libc-alpha review process like
>> for master and I expect interested parties including Cavium to
>> help maintaining the branch.
>>
>> Current glibc policy is that when a glibc port is merged into
>> mainline it receives an ABI bump. We will do our best to maintain
>> ABI stability on the branch, but whether the ABI is maintained at
>> the time of merge depends on the upstream glibc community.
>>
>
> What are the plan for maintenance in near future in case kernel
> support never lands? Would ARM, Cavium, and other interested
> parties to keep maintain both kernel and glibc branches indefinitely
> in such cases?
>
then the branch will be left alone as a reminder
for future generations.
> I am asking it because for ABI merge on glibc without the current
> requiring bump might be easier to manage if we an outlined plan
> (and a fallback one if we continue without kernel support).
>
we are proposing the branch to make it possible to
build and test ilp32 from a canonical source, which
should help seeding the user base and ecosystem
(lack of which the kernel side was concerned about).
this is more work compared to upstream maintenance
(on both glibc and linux side), but the point of it
is that it avoids the even more work of indefinite
maintenance of a target that nobody might care about
in two years time. with this in mind i don't think
indefinite out-of-mainline maintenance is realistic.