This is the mail archive of the 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: AArch64 ILP32 abi in glibc

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
>> 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.

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